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>.
Description: This is a digitally signed message part