Brief article on benchmarks of Python repository with leading DVCSen

[Matthieu Moy]

Nicholas Allen <nick.allen at onlinehome.de> writes:

> My understanding of git (which is most likely old and obsolete so be
> easy on me!) is that it doesn't track file or directory renames
> explicitly.

It doesn't track them, but it detects them. This is a design choice,
and just saying "this is bad" is not an argument. An argument is a
real-life case where this fails, and where bzr does a better job.

Otherwise, I could also do it for bzr Vs MS-Word: bzr's management of
changes is bad, because it doesn't _record_ explicitely the text I
added, and the one I removed, it detects it after-the-fact with a diff
algorithm. MS-Word is better because it tracks the modifications as I
do them. Therefore, bzr is bad, and MS-Word is good (now, try both,
and tell me which one you actually prefer for revision control ...).

Bzr's approach does have advantages, but you shouldn't forget the
drawbacks when you talk about it. I can give you a real-life use-case
(we had it on Emacs-DVC development):

  bzr rm --keep file
  # Oups, my bad, this is not what I wanted.
  bzr add file
  
In Git, this is a no-op. In bzr, this is an unforgivable sin, and this
will mess-up merging for everybody if upstream ever merge from this
guy. Same problem if people use other ways to exchange code than bzr.
Create a file in your repository, commit it, then give the file to
someone else by sending the file, or a plain patch, or whatever is not
bzr, and then you'll get different file IDs, and merging will be
broken (and actually, repeted merges will be repeatedly broken).

The file-id mechanism does a great job when everybody use _only_ the
VCS, and when you always use it correctly, but it's a non-forgiving
mechanism, and Git has chosen very explicitely not to use that
approach (and the guy who took that decision had been using a VCS with
file-ids on a large project for a while, namely BitKeeper and the
Linux Kernel).

> The contents of the file may have changed drastically when
> a class is renamed. When I merge from someone else I need the
> changes they made to go into the correct class.

If the file changes _so_ drastically, it's a rewrite, and you have no
hope to merge old code into a rewrite, whether it's Bzr or Git.

> I also want a conflict when a file is renamed differently in 2
> different branches and then merged.

Which Git does.

-- 
Matthieu