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

[Martin Geisler]

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

> Martin Geisler <mg at aragost.com> writes:
>
>> Ben Finney <ben+bazaar at benfinney.id.au> writes:
>>
>>> Great: The bug is that Mercurial knows the difference between a
>>> request to ‘hg mv foo bar’ versus a request to copy+delete, but
>>> fails to maintain that distinction in the revision data.
>>
>> I've asked you many times, but you have failed to demonstrate why it
>> is important to maintain the distinction. Please don't ignore this --
>> show a situation where Mercurial fails to merge the same nice way as
>> Bazaar does because Mercurial "only" has a copy+delete to work with.
>
> I don't know why you're restricting the scope to merge; this is a
> problem even if it doesn't affect merge.

Okay, I'm restricting the scope to merge and log: this is where you want
the rename information to be used -- this is where it *matters*.

It's critically important Mercurial handles renames correctly at merge
time. This is what allows you to shuffle files around like mad (ehem,
refactor your Java code), and still merge with people who have worked on
the old files.

Likewise, it's critically important that log, annotate, ... can show you
the history of a file -- also across renames.

> Mercurial fails to support the distinct operation that is requested
> with ‘hg mv foo bar’, Bazaar supports it correctly, that's why I'm
> saying Bazaar's behaviour is superior here and Mercurial's is buggy.

But it does support it -- the output may just look funny to you.
However, the output is exactly as documented in 'hg help status'.

>> That's good -- can you then please tell me how this affects Bazaar's
>> behavior in a way that copy+delete doens't do for Mercurial? I mean
>> *merge* behavior since merging is a killer feature of a DVCS.
>
> I don't see why that one feature should constrain the set of features
> we want to behave well.

If you accept that Mercurial has no rename (but copy+delete), then
you'll see that even 'hg status' behaves well. You'll also notice that
rename can be implemented so that merge works well using those
primitives.

>> If you only care
>
> I care about many things :-) but am trying to communicate a particular
> behavioural flaw since I trust you are sincere about wanting to
> understand it.

I'm starting to understand that you call 'hg status' behavior. I call it
simply reporting stored data. Nothing is acted upon there -- it is just
listing what it knows.

Merging, on the other hand, is behavior: there you take two branches and
compute a new working copy. The behavior of Mercurial is very important
here and from what I've seen, the behavior is correct.

>> Now, Bazaar has no 'copy' concept:
>>
>>   https://bugs.launchpad.net/bzr/+bug/269095
>
> Does it affect behaviour in some manner that is semantically
> significant? If so, I'm happy to consider that a bug too, if you like.

No, I wrote that it's not a bug... that was in the part you did no
quote... I also wrote that copy is the basis for rename and that Bazaar
could concievably have used copy+delete too.

That was an attempt to broaden your perspective -- to make you see that
"rename" might not be the fundamental primitive here.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111025/51fa9cb0/attachment.pgp>