← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/news.txt

  • Committer: Martin von Gagern
  • Date: 2011-06-01 12:53:56 UTC
  • mto: This revision was merged to the branch mainline in revision 6009.
  • Revision ID: martin.vgagern@gmx.net-20110601125356-lwozv2vecea6hxfz
Change from no_decorate to classify as name for the argument.

The command line switch remains as --no-classify, to keep backwards
compatibility.  Users are free to include --no-classify in an alias, and
still use --classify to change back.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/news.txt
1
 
Bazaar-NG Development News
2
 
**************************
3
 
 
4
 
 
5
 
2005-02-20
6
 
==========
7
 
 
8
 
* Added documentation of `patch pools <pool.html>`_, explication of
9
 
  commands in terms of file state transitions, `uncommit
10
 
  <kill-version.html>`_, `journalling <interrupted.html>`_ through
11
 
  recording changesets.  Feedback from Aaron on some of the design
12
 
  documentation.
13
 
 
14
 
* Much cleaner ``diff`` and ``status`` commands, based on a new Tree
15
 
  class that abstracts access to either a current working copy or a
16
 
  historical revision.
17
 
 
18
 
* ``remove`` command now both removes the working copy and updates the
19
 
  inventory, and has a new alias ``rm``.  
20
 
 
21
 
* Basic local versioning works well::
22
 
 
23
 
    % bzr init   
24
 
    % echo 'int main() {}' > hello.c
25
 
    % bzr add hello.c
26
 
    % bzr commit 'my test program'
27
 
    % bzr status
28
 
    U    hello.c
29
 
    % echo 'int main() { return 0; }' > hello.c 
30
 
    % bzr status                               
31
 
    M    hello.c
32
 
    % bzr diff        
33
 
    --- old/hello.c 
34
 
    +++ new/hello.c 
35
 
    @@ -1,1 +1,1 @@
36
 
    -int main() {}
37
 
    +int main() { return 0; }
38
 
    % bzr commit 'fix return code'
39
 
    % bzr log
40
 
    ----------------------------------------
41
 
    revno: 1
42
 
    committer: mbp@sourcefrog.net
43
 
    timestamp: Wed 2005-02-16 11:39:13.003095 EST +1100
44
 
 
45
 
    my test program
46
 
    ----------------------------------------
47
 
    revno: 2
48
 
    committer: mbp@sourcefrog.net
49
 
    timestamp: Wed 2005-02-16 11:43:13.010274 EST +1100
50
 
 
51
 
    fix return code
52
 
    % bzr status
53
 
    U    hello.c
54
 
    % bzr rm hello.c
55
 
    % ls
56
 
    % bzr status    
57
 
    D    hello.c
58
 
    % bzr commit 'this program sucks!'
59
 
    % bzr stauts
60
 
    bzr: error: unknown command 'stauts'
61
 
    exit 1
62
 
    % bzr status
63
 
    %
64
 
 
65
 
 
66
 
 
67
 
* Many internal/hacker commands: ``revno``, ``get-inventory``,
68
 
  ``get-file``, ...
69
 
 
70
 
* Most of the implementation is split into reasonably clean objects:
71
 
  `Branch`, `Revision`, `Tree`, `Inventory`.  I think these will give
72
 
  a good foundation for non-intrusive remote operations.  They 
73
 
  live in submodules of `bzrlib`.
74
 
 
75
 
 ====== ==================================
76
 
    596 bzr.py
77
 
    608 bzrlib/branch.py
78
 
     39 bzrlib/errors.py
79
 
     25 bzrlib/__init__.py
80
 
    320 bzrlib/inventory.py
81
 
    126 bzrlib/osutils.py
82
 
     66 bzrlib/revision.py
83
 
    173 bzrlib/store.py
84
 
    107 bzrlib/tests.py
85
 
     62 bzrlib/trace.py
86
 
    239 bzrlib/tree.py
87
 
     41 bzrlib/xml.py
88
 
 ------ ----------------------------------
89
 
   2402 total
90
 
 ====== ==================================
91
 
 
92
 
 
93
 
* After feedback and reflection I have decided not to use `SHA-1
94
 
  hashes`__ as the main identifier of texts, inventories, revisions,
95
 
  etc.  It would probably be safe, but there is a certain amount of
96
 
  concern (or even FUD) about the security of these hashes.  Since
97
 
  they cannot be trusted to be safe in the long term, it is better
98
 
  just to use something cheaper to compute, and equally unique in the
99
 
  absence of malice: UUIDs.
100
 
 
101
 
__ hashes.html
102
 
 
103
 
  We now store the SHA-1 of files, but use it only as a check that the
104
 
  files were stored safely.  At tridge's suggestion we also keep the
105
 
  size, which can catch some classes of bug or data corruption::
106
 
 
107
 
    % bzr diff
108
 
    bzr: error: wrong SHA-1 for file
109
 
    '680757bf-2f6e-4ef3-9fb4-1b81ba04b73f' 
110
 
    in ImmutableStore('/home/mbp/work/bazaar-ng/toy/.bzr/text-store')
111
 
      inventory expects d643a377c01d3e29f3e6e05b1618eb6833992dd0
112
 
      file is actually 352586b84597ea8915ef9b1fb5c9c6c5cdd26d7b
113
 
      store is probably damaged/corrupt
114
 
 
115
 
 
116
 
2005-02-27
117
 
==========
118
 
 
119
 
Revisions are now named by something based on the username and date,
120
 
plus some random bytes to make it unique.  This may be a reasonable
121
 
tradeoff against uniqueness and readability.   This same id is used by
122
 
default for revision inventories::
123
 
 
124
 
  mbp@sourcefrog.net-20050220113441-34e486671a10f75297e03986
125
 
 
126
 
Keeping them separate is still a good thing, because the inventory may
127
 
be large and we often want only the revision and not the inventory.
128
 
It is possible for the revision to point to an older inventory if it
129
 
has not changed (but this is not implemented yet.)
130
 
 
131
 
Tridge pointed out some `possible performance problems`__ with the
132
 
assumption that we can simply compare all files to check for changes. 
133
 
 
134
 
__ unchanged.html
135
 
 
136
 
XML has newlines to make it a bit more readable.
137
 
 
138
 
Nested subdirectories are now supported down to an arbitrary depth.
139
 
 
140
 
bzr can successfully import and reproduce itself.
141
 
 
142
 
 
143
 
 
144
 
ongoing
145
 
=======
146
 
 
147
 
* Systematic command-line handling and option parsing, etc.
 
 
b'\\ No newline at end of file'