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

[Martin Geisler]

Brian de Alwis <briandealwis at gmail.com> writes:

> On 22-Oct-2011, at 9:11 PM, Ben Finney wrote:
>> 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.
>
>
> On 24-Oct-2011, at 3:57 AM, Martin Geisler wrote:
>> 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.
>
> An example where this matters:
>
>   * Ben commits a change renaming directory foo/ to bar/
>   * I commit a parallel change adding a new file to foo/
>
> What should happen if Ben merges my change or I merge Ben's change?
> With bzr, my file is put in bar/. With Mercurial, as I understand from
> you, the file is put in foo/.

No, it's moved into bar/ as well since Mercurial will interpret the
rename of foo/* to bar/* by Ben as a directory rename.

So new files added to foo/ in parallel with this are moved into bar/:

  http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/73117

> This situation has actually happened to me on more than one occasion,
> notably when dealing with Java refactorings, and when re-organizing
> the contents of a project.

Yes, it happens a lot in real life. If Mercurial failed to merge
correctly here, then I would call it a serious bug.

-- 
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/b008f3a8/attachment.pgp>