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

[Brian de Alwis]

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

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.

Brian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2759 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111024/e221126c/attachment.bin>