Brief article on benchmarks of Python repository with leading DVCSen

[Matthieu Moy]

Talden <talden at gmail.com> writes:

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

That is an argument _in favor_ of dealing with file names the same way
you deal with code content. Any decent VCS detect content changes with
a diff algorithm, and you still didn't give an argument to do it
another way for file names.

> There's no point arguing
> * Git doesn't track renames - if that's important to you, git isn't
> for you

_Tracking_ renames is important for no one. _Managing_ renames is
important, and Git is very good at that.

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

The attitude of Git is to refuse arguments like "in theory, it would
be better to do X, so Git should do X". But come with a real-life
use-case where you need something, and the community is then _very_
responsive.

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

Notice how you use the word "detect" here is a positive way, and how
you consider the exact same to be negative for Git.

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

Once you fixed the above, try to fix also

  bzr rm --keep file
  bzr commit
  # oops.
  bzr add file
  
and the "someone used plain patch to add a file" scenario.

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

Which feature does Bzr have that Git doesn't?

Regardless of performance, as someone else said in the thread, I'd use
Git anyway for all the features bzr doesn't have (the staging area,
"rebase -i", the reflog, ...).

So, yes, I could wait for bzr to catch up with Git both in
performances and features, but what's the point?

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

AFAIK, Bzr doesn't have support for copies, while Git has (for
example, "git blame" will track code movement and copies between files
like no other VCS do as of now). It may have changed recently, I don't
know.

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

And can a merge still happen in the files after such huge
modifications? I mean: did you do a diff3 or diff+patch manually and
see the amount of conflicts?

-- 
Matthieu