two factors for switching to Mercurial

Martin Geisler mg at daimi.au.dk
Tue Jun 17 04:59:09 CDT 2008


"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

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.


More information about the Mercurial mailing list