On Wed, 2005-08-31 at 00:17 +0200, martin f krafft wrote:
> Could you please elaborate on this?
Hmm. Where to start :0. perhaps with storage. bzr currently stores the
different variations of each file that is versioned in 'stores', which
are a collection of files named by their hash, gzipped. (Its been doing
this since January). We're about to migrate to using a thing called a
'weave', which linear time annotation with respect to the number of line
variations in a file. Once we've done this transition, the storage will
look somewhat like sccs. When a commit occurs, a minimum of 2 file
alterations occur:
- we create a new 'revision' file which records the date, user, log
message, and a reference to an inventory of the tree at the time of the
commit.
- we append the hash of the revision to the revision-history file in
the .bzr directory.
- If the shape of the tree has changed - if files have been altered or
added or deleted - then we record a new inventory for the tree, which
has the full shape of the tree. The storage we use works fine on
windows, Mac OS X, and on Un*x. It also works happily over sftp and http
- no smart server is required. (We have plans for an optional smart
server post release).
So this looks rather like a 'snapshot' based system. However, we use
persistent unique file identifiers to track renames and to allow merging
between branches with files that have been renamed, without needing to
calculate back in time for the current name of the file. (This was one
of the key things GNU Arch does that bazaar-NG has incorporated).
Merges are tracked at both the file and revision level - a file has
ancestors of its own. Thus the system can represent a merge of a single
file from a remote branch without a full merge occuring, OR a partial
merge where some changes are deferred - neither rejected nor accepted.
We haven't taken full advantage of this capability yet, but I think it
will make working with cherry picking scenarios very enjoyable.
Branches are identified by value - if two branches have the same
revision-history they are identical, we can identify common prefixes to
identify where divergence has occured, and with the symmetrical parents
of revisions we can join branches up again when they have converged.
Branching can be as simple as a 'cp -al' from one directory to another,
or you can use the builtin 'branch' command which brings over only the
history for the one branch to your new branch ('stores' can share data
for many branches).
What else - oh, we have plain text diffs for use in sending to mailing
lists, there is no namespace for branches - you manage them just like
one can manage directories on disk, we're optimising for the common case
in most operations (though identifying that can be troublesome). We have
designs for supporting a 'CVS-style' operation where there is a common
branch many people commit directly to. The library code essentially
supports this now, but there is no UI to configure a tree to use it.
Hope this helps..
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
Attachment:
signature.asc
Description: This is a digitally signed message part