Proper tracking of file-level operations: rename, directories, merges

[Martin Geisler]

Ben Finney <ben+bazaar at benfinney.id.au> writes:

Hi Ben,

Thanks for taking me up on the challenge! It would be great if you could
either demonstrate a bug that we can fix in Mercurial, or if you would
realize that we're doing okay. Win-win situation :)

> Martin Geisler <mg at aragost.com> writes:
>
>> Ben Finney <ben+bazaar at benfinney.id.au> writes:
>>
>> > * Proper tracking of all changes in the history, including renames
>> >   and merges.
>>
>> Please stop implying that Mercurial has "improper" tracking of
>> changes. You may say that about Git, for example, since it infers
>> renames after the fact, but Mercurial tracks renames explicitly, just
>> like Bazaar.
>
> Not of directories, it doesn't.

Yes, that is true -- directory renames are *defined* to mean "all files
in foo/ was moved to bar/". As far as I can see, this is equivalent to
actually tracking directories.

>> I'll keep protesting until you demonstrate a bug in the handling of
>> renames and merges in Mercurial.
>
> Mercurial:
>
> =====
>
> $ hg status
> A bar/beans
> A bar/eggs
> A bar/spam
> R foo/beans
> R foo/eggs
> R foo/spam
> =====

What Mercurial is telling you here is that "bar/beans" was added and
"foo/beans" was removed. If you use "hg status --copies", you'll see
that Mercurial is well aware that the addition of "bar/beans" is a copy
from "foo/beans".

> Bazaar:
>
> =====
>
> $ bzr mv foo bar
> foo => bar
>
> $ printf 'Lorem morit ipsum\n' > bar/eggs
>
> $ bzr status
> renamed:
>   foo/ => bar/
> modified:
>   bar/eggs

Yes, that is much nicer *output*.

> =====
>
> I consider it a bug that the file-level change made (rename ‘foo’ to
> ‘bar’) is not reflected as such in Mercurial, but instead pretends
> that some files were added and others removed.

There is not pretending going on here. It's really not honest to call it
that. Mercurial tracks the copy+delete carefully and uses this when
making future merges.

> Bazaar tracks the rename as a rename, regardless of any other changes
> made in the same revision. Hence it doesn't need to infer it after the
> fact, and can present it as such in any query about the revision.

It's purely a matter of output. You did not demonstrate a problem with
how Mercurial merges files involving renames -- you demonstrated that
Mercurial gives sub-optimal output in this case.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/