Future bzr features: split file tracking and type-specific merging

John Arbash Meinel john at arbash-meinel.com
Fri Apr 28 04:43:45 BST 2006


Andrew Lambe wrote:
> From second hand discussions of git, at its lowest level, git is mainly
> versioning "chunks of content" based on its hash rather than whole
> files.
> This creates a lot of bloat which is why git is storage inefficient,
> and it can be difficult to actually use all that tracking.
> This kind of brute force code tracking may be good or necessary for
> Linus's kernel management (which is why he created it), but bzr's goals
> of flexibility, efficiency, and ease-of-use are not really compatible
> with this approach.
> 
> All I really want for tracking file splits is an easier way to audit
> the origin of a portion of code.
> For bzr it could be as simple as:
> bzr add --split-from original.file
> new.file.with.code.from.original.file
> This could store a property indicating that for the revision about to
> be committed some or all of "new.file.with.code.from.original.file" was
> once part of "original.file".
> This property could then be used by plugins for various purposes and
> could be noted on file annotations.

So how does git track which chunk is which? Very interesting, though.

I'm not sure what we could do for bzr. From the simple standpoint that
each file has a unique identifier, and that is kind of a key feature.
Its how we handle rename sensitive merging, and a few other nice things.

The only thing I could think of goes along with ID aliases. Where you
might say "after this revision file_id A == file_id B".
It has been asked in the past to allow file_id aliases (so if I add a
particular file, and you add the same file in a different branch, we can
merge and just identify them as the same file).

But it is kind of the inverse of the proposed aliases. Instead of 1 file
having 2 ids, it is 2 files having 1 id [sort of].

Just thinking about it, I would say we probably *could* store some sort
of backpointer, which just says that this file was spawned from that file.

So possible, but the devil would be in the details.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060427/3c543aca/attachment.pgp 


More information about the bazaar mailing list