Brief article on benchmarks of Python repository with leading DVCSen

[Talden]

I would expect that most java shops will lean heavily towards explicit
renames and folder tracking specifically because of the tight
relationship between folder structure, file naming and code content.

But then this A is better than B is always a horses for courses argument.

Lets face it, the lack of atomic rename in Subversion was "a design
decision" that has prompted one of the most discussed and requested
bugs in the database.  If you don't need them you don't care, it's
just that many people need them.

There's no point arguing
* Git doesn't track renames - if that's important to you, git isn't for you
* Bazaar performance is poor but improving - if the bits that are slow
are a problem, don't use bazaar (or perhaps just not yet)

The Bazaar team is working hard to improve performance and make as
much of the workflow a personal choice - I can't say I see the same
from Git, there it seems to be more an attitude of "if git doesn't do
it, you don't need it"...

Oh and this example of a weakness in bzr.

>  bzr rm --keep file
>  # Oups, my bad, this is not what I wanted.
>  bzr add file

Surely this is just a UI bug. bzr could easily detect replaces (an rm
and an add with the same path) and check the contents for a match and
treat the add as a revert of the rm (a "--force-replace" option on add
could support the current behaviour).

To me this is an example of something screaming for a patch to fix - I
really must put some time into learning python and the bzr codebase.

At the moment, of Git, Mercurial and Bazaar, I'm mostly in the Bazaar
camp (and am following them to decide which we will progress to from
Subversion) but then we're not migrating yet so we have time to wait
for the performance to catch up with the feature-set.

>> 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.

No it's refactor - it might change too drastically for Git to detect
it as a rename yet still be useful for merges.  Just as the Bazaar
list can't handwave away the opinions of potential adopters about
their own workflow, gittites can't handwave away the fact that renames
(and copies) are important to some teams.

NB: Someone in our team is bitten by the lack of atomic rename in
Subversion at least once a month.  The changes are such that Git is
unlikely to have detected it after the fact.

--
Talden