two factors for switching to Mercurial

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Tue Jun 17 06:25:07 CDT 2008


On Tue, Jun 17, 2008 at 11:59 AM, Martin Geisler <mg at daimi.au.dk> wrote:
> "Peter Arrenbrecht" <peter.arrenbrecht at gmail.com> writes:
>
>> On Tue, Jun 17, 2008 at 9:26 AM, Martin Geisler <mg at daimi.au.dk> wrote:
>>> For non-empty directories I can see a potential advantage of being
>>> able to version it: if I rename a directory in my clone and another
>>> guy makes a new file within the directory in his clone (before
>>> seeing the rename), then upon merging the right thing can happen if
>>> Mercurial would track the directory rename.
>>
>> Hg actually assumes that when all the files in a particular
>> directory have been renamed to a different directory that you meant
>> to rename the directory as such.
>>
>> See also: http://www.selenic.com/mercurial/bts/issue850
>
> Ahh, excellent! I didn't know that now. Just to be clear, I just
> tested Mercurial 1.0.1 with this sequence of commands:
>
> rm -r repo-{a,b}
> hg init repo-a
> cd repo-a
> mkdir a
> echo hello > a/foo.txt
> hg add
> hg commit -m 'Added a/foo.txt'
> cd ..
> hg clone repo-a repo-b
> cd repo-a
> hg rename a b
> hg commit -m 'Renamed a -> b'
> cd ../repo-b
> echo hi > a/bar.txt
> hg add
> hg commit -m 'Added a/bar.txt'
> hg pull ../repo-a
> hg merge
> hg commit -m 'Merged'
>
> And the end result is that we end up with a 'b' directory containing
> both 'foo.txt' and 'bar.txt' after the merge, even though 'bar.txt'
> wasn't explicitly moved from the 'a' directory to the 'b' directory.
>
> I guess this feature negates the claims of Bazaar people that they
> have better rename support than Hg... See this link:
>
> http://bazaar-vcs.org/BzrVsHg#head-db787575713f92ef301caf242b5a0ce8438c6df5
>
> and this:
>
>  http://www.markshuttleworth.com/archives/126

Ahem. Not exactly. Hg infers directory moves from file moves. Now this
may or may not have been the mover's intention. I agree it's rather
unlikely to ever be a serious problem, but from a theoretical point of
view, Bzr has the upper hand here.

The issue I cited above,
http://www.selenic.com/mercurial/bts/issue850, demonstrates this case.
Bzr handles both cases correctly, following the users intention. Hg
does not.

-parren


More information about the Mercurial mailing list