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