1
Bazaar-NG Development News
2
**************************
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
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
18
* ``remove`` command now both removes the working copy and updates the
19
inventory, and has a new alias ``rm``.
21
* Basic local versioning works well::
24
% echo 'int main() {}' > hello.c
26
% bzr commit 'my test program'
29
% echo 'int main() { return 0; }' > hello.c
37
+int main() { return 0; }
38
% bzr commit 'fix return code'
40
----------------------------------------
42
committer: mbp@sourcefrog.net
43
timestamp: Wed 2005-02-16 11:39:13.003095 EST +1100
46
----------------------------------------
48
committer: mbp@sourcefrog.net
49
timestamp: Wed 2005-02-16 11:43:13.010274 EST +1100
58
% bzr commit 'this program sucks!'
60
bzr: error: unknown command 'stauts'
67
* Many internal/hacker commands: ``revno``, ``get-inventory``,
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`.
75
====== ==================================
80
320 bzrlib/inventory.py
88
------ ----------------------------------
90
====== ==================================
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.
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::
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
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::
124
mbp@sourcefrog.net-20050220113441-34e486671a10f75297e03986
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.)
131
Tridge pointed out some `possible performance problems`__ with the
132
assumption that we can simply compare all files to check for changes.
136
XML has newlines to make it a bit more readable.
138
Nested subdirectories are now supported down to an arbitrary depth.
140
bzr can successfully import and reproduce itself.
147
* Systematic command-line handling and option parsing, etc.
b'\\ No newline at end of file'
added
removed
doc/news.txt
