Brief article on benchmarks of Python repository with leading DVCSen

[Talden]

>> No, I meant what I said.  We NEED tracked renames.  It is necessary to
>> be able to trace the history of a class and file names, locations in
>> the tree and contents change during refactoring.  Changing the package
>> changes the package statement, often changes imports and sometimes
>> changes invocations within the file (and rarely does the refactor
>> occur just to rename so naturally there are content changes too).
>> Being able to trace back in history through several rename/moves has
>> been invaluable often - failure to merge forward through the renames
>> has been equally painful, often.

> I find this statement puzzling, but I may miss something since I don't
> use IDE. My main languages are C and python nowadays - python is similar
> to java in the sense that filenames are significant, and import
> statement need to be changed when file are renamed. But still, I don't
> find rename tracking that useful. If filenames change in a branch, you
> need to coordinate with other people anyway for the changes to be
> meaningful for anything non trivial - or are java IDE powerful enough to
> make all this automatic ? But certainly, if that's the case, it means
> the IDE needs to understand java (needs to be able to understand where
> classes start and all), and at this point, this could be done in git as
> well.
>
> To me, this at least shows that saying that git cannot track content
> reliably is bogus: if IDE can do it, git can do it, in principle at
> least. And if one say that git cannot do it, then IDE cannot do it
> either, no ?

The IDE has more information when performing a refactor than Git has
when trying to detect renames.  The IDE has a starting state and a
user gesture and produces changes forward of this point, noting
renames as it goes.  The user may make more changes before committing.

Git when working backwards to guess renames has to work it out from
the list of new files and the list of removed files and can only match
them by the content of the files in those two states - a tough call.

Bazaar, knowing the renames explicitly knows only that file A became
file B and merging changes to A should migrate through to B.  File B
can be different enough to make it unreliable (or at best very hard)
to guess that it is from file A yet still be useful to automate
forward merging.

Yes the IDEs do a lot of the grunt work for you.  If they didn't, hand
editing all of the the verbosity of java during these refactors would
make a grown man cry.

--
Talden