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:
>>
>>> Martin Geisler <mg at aragost.com> writes:
>>
>> The point is that you cannot see the difference between a "rename"
>> and a "copy+delete". If you can, then we have a bug in Mercurial (and
>> we would like to fix it).
>
> 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've already demonstrated that Mercurial does merge correctly when you
rename a directory: if you create foo/x, then it will moved to bar/x
when the foo->bar rename is merged. The bar/x file will of course know
where it comes from so log/annotate/... works.

Notice that it's actually the copy part that is interesting: I can do

  hg copy foo bar

and I'll get the same behavior on a future merge. Changes made to foo/x
before the merge will be copied into bar/x too. The delete part is not
important for the merge semantics.

Now, Bazaar has no 'copy' concept:

  https://bugs.launchpad.net/bzr/+bug/269095

but if it had, then you would perhaps also have implemented rename as
copy+delete.

>> You can't really know from that output -- it could just be smart and
>> formatting the output nicely for you :) (I know that's not the case
>> and that Bazaar really tracks directories.)
>
> I'm happy to talk about it in terms of behaviour. Bazaar behaves
> correctly, in that it preserves the ‘bzr mv foo bar’ operation as a
> discrete action. I don't care about the representation except to the
> extent that it affects the behaviour.

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.

If you only care about output behavior of 'hg status' vs 'bzr status',
then yeah... looking at 'hg status' sucks when you're renaming things.

>> You say the distinction is important, so I would like you to explain
>> exactly when the distinction becomes important in a future merge.
>
> The distinction becomes important because the intent of the user with
> ‘hg mv foo bar’ is to move a directory, which has a different semantic
> meaning from moving entries within that directory.

What is the difference in semantics? What should Bazaar do if it had
copy+delete that it should not do in a normal rename?

>> You still doubt that it's just an output issue?
>
> You've already said, and IIUC confirmed throughout this thread, that
> the failure is in the representation of Mercurial revision data.
>
> If you can fiddle the Mercurial behaviour without changing the
> representation, fine; but that would seem to contradict what you've
> already said, so yes, I doubt it.

I don't understand what you're saying here. I've confirmed many times
that the difference is that Mercurial implements rename as copy+delete.
It's not a failure, it's a difference in representation. I could claim
that Bazaar "fails" to represent a copy... but I wouldn't since I think
copies are pretty rare and so "settling" for a rename primitive is okay.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/