Brief article on benchmarks of Python repository with leading DVCSen

[David Cournapeau]

Talden wrote:
>>> 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.
>   

Ok - as you see, I am not familiar with IDE so much. But wouldn't
"commit often" be a solution ? I have seen people saying that they
commit their code once a day, but that sounds insane to me if the tool
enables commit early/commit often. The problems you mention are linked
to the number of operations you do between commit - personally, when I
"refactor" some code, I make a branch in git, and then commit regularly.
The branch is the unit of interest, not the commit. Would solve most
problems ?

cheers,

David