Bzr development stopped

Stephen J. Turnbull stephen at xemacs.org
Wed Nov 28 04:04:22 UTC 2012


Roland Mas writes:

 > > As far as tracking renames goes, there's a very simple strategy for
 > > guaranteeing 100% accuracy for git's inference algorithm:

 >   Except it doesn't really work 100%.

This sounds like a bug in git, not in the algorithm.  git has the
information needed to determine that the file was renamed on the
branch within the scope of the merge algorithm (ie, back to the node
where the branch separated from the mainline), but it chooses to rely
on current names instead.

There's nothing to stop bazaar from keeping additional metadata needed
to implement this properly, even if the git modules responsible for
this refuse to change.  (IMHO they should fix this; the content does
have a new name, and the changes to the old foo should follow the
content to the new name, so it's a bug according to Linus's "stupid
content tracker" definition of git.  But they might choose not to.)

 >   I don't think that worrying is misplaced; it may be unjustified, but I
 > claim my right to worry until I'm sure I shouldn't :-)  Also, as shown
 > above, I believe at least some of the nice features of Bazaar would be
 > lost.  Probably not all, but at least one.

You're assuming that Bazaar would simply become a pretty face for git.
I don't think that would be acceptable to anybody[1], so I think
worrying about it at this stage is indeed misplaced.  I would expect
that the developers and users would demand that system tests for VCS
behavior continue to pass before a change in storage would be allowed.

Footnotes: 
[1]  Except people who think that git is already perfect.  I challenge
you to find one such person in the Bazaar community!




More information about the bazaar mailing list