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

[John Yates]

Ben,

I think that you are "making a mountain out of a mole hill".

Bzr only knows that I did a rename if I issue "bzr mv foo bar".  If I have 
failed to teach my fingers to type those extra 4 keys and ask bzr to 
reconstruct my renames after the fact then I am in exactly the same boat 
as hg.

Further, if you insist on going down the path that a delete plus an add is 
not equivalent to a rename then what is to prevent me from arguing that in 
the context of an edit a delete at one position and an insert at another 
fails to capture the fact that I think of my edit as a move operation?

/john




From:   Ben Finney <ben+bazaar at benfinney.id.au>
To:     bazaar at lists.canonical.com
Date:   10/24/2011 08:23 AM
Subject:        Re: Proper tracking of file-level operations: rename, 
directories,    merges
Sent by:        bazaar-bounces at lists.canonical.com



Martin Geisler <mg at aragost.com> writes:

> Ben Finney <ben+bazaar at benfinney.id.au> writes:
>
> > Martin Geisler <mg at aragost.com> writes:
> >
> >> Yes, that is true -- directory renames are *defined* to mean "all
> >> files in foo/ was moved to bar/".
> >
> > Defined by whom? That's not the operation I performed, and it's not
> > the result I want to see in the VCS.
>
> Maybe I should have been more clear: in Mercurial, a directory rename is
> defined to mean "all files in foo/ was moved to bar/".
>
> My claim is that this is the same as defining it as meaning "directory
> foo/ was moved to bar/". You hint that this is wrong, but you provide no
> concrete way for me to test this.

I'm saying that it's wrong because it doesn't represent the intention of
the user making the change ? the one who issues ?hg mv foo bar?.

> >> 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".
> >
> > A copy? That's still not what has happened on the filesystem, though.
>
> But how can you tell?

You cant tell post-hoc. But you *can* tell what the user of the VCS has
asked for, explicitly.

> 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.

> > Yes. It shows that Bazaar is correctly representing the change
> > operations I performed and told it.
>
> 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.

> 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.

That semantic meaning is information that should, I maintain, be
preserved and presented distinctly to the future recipient of that
revision data.

> >> It's purely a matter of output.
> >
> > If that's true, how is it any less of a bug?
>
> 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'll be happy to call this a bug in the Mercurial output.

s/output/behaviour/ and we can agree on that.

-- 
 \      ?Software patents provide one more means of controlling access |
  `\      to information. They are the tool of choice for the internet |
_o__)                                     highwayman.? ?Anthony Taylor |
Ben Finney