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

>> > 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.
>
> Yes. That's what is wrong.

Read on... it's just not added without context.

>> 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? 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). But if you can't then it's
okay for Mercurial to implement "rename" and "copy+delete".

>> > $ bzr status
>> > renamed:
>> >   foo/ => bar/
>> > modified:
>> >   bar/eggs
>>
>> Yes, that is much nicer *output*.
>
> 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.)

>> 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.
>
> Right. That's the bug: that Mercurial's representation loses the
> important distinction between “renamed a filesystem entry (that
> happens to be a directory)” versus “renamed a lot of other filesystem
> entries”. The former is what I told the VCS about, and it's what I
> expect to see when I ask the VCS what has changed.

You say the distinction is important, so I would like you to explain
exactly when the distinction becomes important in a future merge. There
must be some sequence of renames that makes Mercurial mess up a merge?

>> 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? Please don't spread
fears and doubts without corresponding shell scripts to back them up.

I'll be happy to call this a bug in the Mercurial output.

> I think from what you're telling me, though, the bug is in Mercurial's
> representation of the change: it doesn't track the directory as a
> filesystem entry which can be changed.
>
> The filesystem doesn't infer directories; they are entries with their
> own attributes. The project structure doesn't infer directories; they
> are part of the project (even empty directories). The VCS
> representation should at least support that in its dialogue with the
> user.

Yes, that would be nice. Unfortunately, we cannot just go change 'hg
status' to report file or directory renames since that would conflict
with our strict backwards compatibility rules.

What I can do is write an extension that will fix the output.

-- 
Martin Geisler

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