Subject: Re: VCS comparison table

From: Jakub Narebski <[email-masked]>
Date: Tue, 17 Oct 2006 21:12:54 +0200

J. Bruce Fields wrote:

> On Mon, Oct 16, 2006 at 11:23:53PM -0700, Junio C Hamano wrote:
>> Aaron Bentley <[email-masked]> writes:
>> 
>> > Johannes Schindelin wrote:
>> >
>> >>> You'll note we referred to that bevhavior on the page.  We don't think
>> >>> what Git does is the same as supporting renames.  AIUI, some Git users
>> >>> feel the same way.
>> >> 
>> >> Oh, we start another flamewar again?
>> >
>> > I'd hope not.  It sounds as though you feel that supporting renames in
>> > the data representation is *wrong*, and therefore it should be an insult
>> > to you if we said that Git fully supported renames.
>> 
>> Not recording and not supporting are quite different things.
> 
> Yes.  There's a risk of confusing a feature with an implementation
> detail.  From http://bazaar-vcs.org/RcsComparisons:
> 
>       "If a user can rename a file in the RCS without loosing the RCS
>       history for a file, then renames are considered supported. If
>       the operation resultes in a delete/add (aka "DA pair"), then
>       renames are not considered supported. If the operation results
>       in a copy/delete pair, renames are considered "somewhat"
>       supported. The problem with copy support is that it is hard to
>       define sane merge semantics for copies."
> 
> The first sentence sounds like a description of a user-visible feature.
> The rest of it sounds like implementation.

The proper description would be: if we get history of file up to rename
unrelated to the history of file before rename ("DA pair"), where
"unrelated" means that SCM doesn't store this relation (or equivalent
information), renames are not considered supported. If we get full
history of file under new name, and unrelated history of file up to rename
("CD pair"), renames are not considered supported ;-)
 
> And git probably has some deficiencies here, but it'd be more useful to
> identify them in terms of things a user can't do.

For example:
 * if we rename (or delete) file on one branch, and then merge changes
   with other branch where such rename didn't make place, do merge do
   the correct thing.
 * can we get whole history of file, before and after rename. Can we do
   this automatically, in one go.
 * do renames are (can be) marked as such in diff output.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git