Discussion:
Info Q article on DVCS - a request and some feedback
(too old to reply)
Ian Clatworthy
2008-05-09 10:26:06 UTC
Permalink
Hi Sebastien,

Well done on your InfoQ article re DVCS tools. It looks quite well
researched and well written. If you're interested, I'd like to provide
some more information on Bazaar. Perhaps it's worth updating the article
to reflect this?

First though, can I make a request? Can you make the exact git, hg and
bzr repos you used available? I'd like to run some more performance
tests using them. More on this at the end of this email.

OK, some feedback on the comparison table you presented:

1. bzr EOL conversion support is under active development by me.
My hope is that Bazaar will support this in 1.6. (We're
packaging the 1.5rc tomorrow so it will miss that.)

2. Partial checkout support is also planned. See
http://bazaar-vcs.org/FilteredViews.

3. Per file commit. You can record per file commit messages,
in addition to the overall commit message, using bzr-gtk.

4. Rebase/Queues. These are both really well supported by Bazaar
plugins. See http://bazaar-vcs.org/Rebase,
http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/ and
http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt.

5. Web access. Bazaar is every bit as good as git and hg here. In fact,
it's far easier to set up static serving over http using Bazaar than
Git. Static http serving is also *much* faster in bzr than in hg.
I suspect bzr is quicker than Git here as well (given our smaller
repo size for many projects) though I'm yet to measure that.

6. I agree that gitweb and hgweb are currently ahead of bzr's options.
Loggerhead - you didn't include that in your table - is pretty good
though if a bit annoying to set up.

7. Under cool extensions, you should mention shelf - part of BzrTools.
(I believe it's directly comparable with git-stash.) bzr-dbus and
bzr-ahavi are also really cool for hackers when sprinting.

8. TortoiseBzr is a Windows tool, not a Linux one. It is currently under
active development. See
http://doc.bazaar-vcs.org/bzr.dev/developers/tortoise-strategy.html.

9. Before Tortoise matures, WildcatBZR is probably the best option
right now for an integrated GUI. It's been tested on OS X and XP
and ought to run on Linux as well. See
http://sorn.net/projects/wildcat-bzr/about.php.

10. Submodules are supported in Bazaar by a related tools called
ConfigManager. See http://bazaar-vcs.org/3rdPartyTools. This
is a common need and we don't cover it yet in the User Guide.
I need to address that soon.

11. In the Migration section (which probably should be called
Interoperability instead?), I'm curious as to why you marked
Bazaar down versus the competition. We believe bzr-svn is actually
the leading option here. See
http://permalink.gmane.org/gmane.comp.gnome.desktop/36309.

Performance. Thanks for your benchmarking. I'm particularly curious
about the clone figures though: most of my benchmarking puts Bazaar
clone ahead of git clone. Did you use a shared repository? I'd be happy
to repeat your tests (and expand them) using a shared repo if you make
the hg and git repos you used available. I've also expanded
http://bazaar-vcs.org/Benchmarks to include a place to reference
independent benchmarks of Bzr vs Git vs Hg performance. Please feel free
to add your article there.

So what section. I'd be very happy to update the BzrVsGit and BzrVsHg
pages on our Wiki if you'd point out which bits are incorrect. These
pages aren't there to "bash" the competition: they are there to point
out our strengths, and to provide links we can point (the never ending
stream of) people to whom ask us why they ought to use Bazaar. As well
as being the right thing to do ethically, it's absolutely in our
interest to ensure those pages are defensible. Please help us by
pointing out explicitly why you think they are "not-all-true".

Ian C.
AUVRAY Sebastien
2008-05-12 19:31:57 UTC
Permalink
Hi Ian,
Sorry for my late answer, I was away.
Your feed back is very much appreciated. I just did a first update of the
article accordingly (also with the comments I saw around). Actually I wanted
to send the article to the three vcs maintainers, but I guess I would have
had to remodel everything again, then new versions are out, new features,
updates needed, benchmarks needs to be replayed (infinite loop)... It's been
already a lot of time to gather all this piece of information, reading,
playing with the three, chatting, and doing those benchmarks (I had this
article idea since February...).

Concerning your request & feedback.
- You'll find the exact git / hg / bzr repositories I used available at
http://seb.auvray.free.fr/dvcs-bench-repo/. I applied the dummy diff (on
dom/src/base/nsDOMClassInfo.cpp) you'll find at the end of this mail*. The
bzr repository is the same as the one you sent to me when I was having
problem using the fast-import plugin (
http://people.ubuntu.com/~ianc/benchmarks/repos/bzr/mozilla.bzr.tar.bz2<http://people.ubuntu.com/%7Eianc/benchmarks/repos/bzr/mozilla.bzr.tar.bz2>).
I had also produced same one while testing your fix.
1 - Ok
2 - Ok
3 - I need to check this.
4 - Yes, I missed that one (also read about it in reedit comments)
5 - I need to check this. The feedbacks I had/read about git/hg web were
better.
6 - I didn't know about Loggerhead.
7 - Yes, some were also advised in reedit comments. I cannot find anything
about bzr-ahavi though (typo ?).
8 - Indeed I must have swapped the linux/windows for Tortoise, still 1) it's
a pain to install it, 2) the launchpad project shows no activity since
2007-08-30 which sounds weird regarding the way to install it (that needs
work) and the features that were made available in bzr since then. Thanks
for the link to the documentation that indeed shows you're still working on
this. Is there anyway to see how it is evolving (any public launchpad
project ?)
9 - Ok, will give Wildcat BZR a try asap.
10 - Ok for this work around.
11 - Interesting link. I put git-svn ahead as I had good feedbacks from it
contrary to bzr-svn. I didn't play with it myself that much.
12 - No I didn't use shared repository but this locally:
bzr clone mozilla.bzr/master/
Some remarks: I know *clone* is no bzr command but an alias for *branch*.
What I wanted to test was the basic cloning (> *xxx clone a b*) without the
network protocol overhead (in case *a* would be http://...)

Concerning the BzrVs* pages, I find them definitely useful and you guys in
the business are the ones who can best compare each other (knowing
implementations, details, ...). But from the answers from Mercurial we could
see it was biased (model chosen critics, implementation choice...) and not
always up-to-date (renaming for hg is fixed (still not for git), merge
architecture (only external tools which is not true since 1.0 version),...).

You also should notice that I kept some points from it in my article and it
also enriched the comparison.

Thanks again for your feedback!
Regards,
Sébastien.

(*)
--- a/dom/src/base/nsDOMClassInfo.cpp
+++ b/dom/src/base/nsDOMClassInfo.cpp
@@ -41,7 +41,10 @@
#include "nsDOMClassInfo.h"
#include "nsCRT.h"
#include "nsCRTGlue.h"
+#include "nsIerviceManager.h"
+/*
#include "nsIServiceManager.h"
+*/
#include "nsICategoryManager.h"
#include "nsIComponentRegistrar.h"
#include "nsXPCOM.h"


On Fri, May 9, 2008 at 12:26 PM, Ian Clatworthy <
Post by Ian Clatworthy
Hi Sebastien,
Well done on your InfoQ article re DVCS tools. It looks quite well
researched and well written. If you're interested, I'd like to provide
some more information on Bazaar. Perhaps it's worth updating the article
to reflect this?
First though, can I make a request? Can you make the exact git, hg and
bzr repos you used available? I'd like to run some more performance
tests using them. More on this at the end of this email.
1. bzr EOL conversion support is under active development by me.
My hope is that Bazaar will support this in 1.6. (We're
packaging the 1.5rc tomorrow so it will miss that.)
2. Partial checkout support is also planned. See
http://bazaar-vcs.org/FilteredViews.
3. Per file commit. You can record per file commit messages,
in addition to the overall commit message, using bzr-gtk.
4. Rebase/Queues. These are both really well supported by Bazaar
plugins. See http://bazaar-vcs.org/Rebase,
http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/ and
http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt.
5. Web access. Bazaar is every bit as good as git and hg here. In fact,
it's far easier to set up static serving over http using Bazaar than
Git. Static http serving is also *much* faster in bzr than in hg.
I suspect bzr is quicker than Git here as well (given our smaller
repo size for many projects) though I'm yet to measure that.
6. I agree that gitweb and hgweb are currently ahead of bzr's options.
Loggerhead - you didn't include that in your table - is pretty good
though if a bit annoying to set up.
7. Under cool extensions, you should mention shelf - part of BzrTools.
(I believe it's directly comparable with git-stash.) bzr-dbus and
bzr-ahavi are also really cool for hackers when sprinting.
8. TortoiseBzr is a Windows tool, not a Linux one. It is currently under
active development. See
http://doc.bazaar-vcs.org/bzr.dev/developers/tortoise-strategy.html.
9. Before Tortoise matures, WildcatBZR is probably the best option
right now for an integrated GUI. It's been tested on OS X and XP
and ought to run on Linux as well. See
http://sorn.net/projects/wildcat-bzr/about.php.
10. Submodules are supported in Bazaar by a related tools called
ConfigManager. See http://bazaar-vcs.org/3rdPartyTools. This
is a common need and we don't cover it yet in the User Guide.
I need to address that soon.
11. In the Migration section (which probably should be called
Interoperability instead?), I'm curious as to why you marked
Bazaar down versus the competition. We believe bzr-svn is actually
the leading option here. See
http://permalink.gmane.org/gmane.comp.gnome.desktop/36309.
Performance. Thanks for your benchmarking. I'm particularly curious
about the clone figures though: most of my benchmarking puts Bazaar
clone ahead of git clone. Did you use a shared repository? I'd be happy
to repeat your tests (and expand them) using a shared repo if you make
the hg and git repos you used available. I've also expanded
http://bazaar-vcs.org/Benchmarks to include a place to reference
independent benchmarks of Bzr vs Git vs Hg performance. Please feel free
to add your article there.
So what section. I'd be very happy to update the BzrVsGit and BzrVsHg
pages on our Wiki if you'd point out which bits are incorrect. These
pages aren't there to "bash" the competition: they are there to point
out our strengths, and to provide links we can point (the never ending
stream of) people to whom ask us why they ought to use Bazaar. As well
as being the right thing to do ethically, it's absolutely in our
interest to ensure those pages are defensible. Please help us by
pointing out explicitly why you think they are "not-all-true".
Ian C.
Ian Clatworthy
2008-05-13 00:24:15 UTC
Permalink
Post by AUVRAY Sebastien
Hi Ian,
Sorry for my late answer, I was away.
Your feed back is very much appreciated. I just did a first update of
the article accordingly (also with the comments I saw around). Actually
I wanted to send the article to the three vcs maintainers, but I guess I
would have had to remodel everything again, then new versions are out,
new features, updates needed, benchmarks needs to be replayed (infinite
loop)... It's been already a lot of time to gather all this piece of
information, reading, playing with the three, chatting, and doing those
benchmarks (I had this article idea since February...).
Concerning your request & feedback.
- You'll find the exact git / hg / bzr repositories I used available at
http://seb.auvray.free.fr/dvcs-bench-repo/. I applied the dummy diff (on
|dom/src/base/nsDOMClassInfo.cpp|) you'll find at the end of this mail*.
Thanks.
Post by AUVRAY Sebastien
|||bzr clone mozilla.bzr/master/|
Some remarks: I know /clone/ is no bzr command but an alias for
/branch/. What I wanted to test was the basic cloning (> /xxx clone a
b/) without the network protocol overhead (in case /a/ would be http://...)
Right. It's a worthwhile test as it's a common operation. The bzr
repository I sent you is already set up as a shared repo. To test
Bazaar's clone speed, here are the commands to run:

cd mozilla.bzr
bzr clone master my-fix

This will be much faster than cloning outside the shared repo.
Post by AUVRAY Sebastien
Concerning the BzrVs* pages, I find them definitely useful and you guys
in the business are the ones who can best compare each other (knowing
implementations, details, ...). But from the answers from Mercurial we
could see it was biased (model chosen critics, implementation choice...)
and not always up-to-date (renaming for hg is fixed (still not for git),
hg has certainly made some improvements to renaming support but, AFAIK,
it still doesn't track directories as first class objects and therefore
doesn't handle their renaming as well as Bazaar does. This isn't just an
implementation choice - it impacts the UI and model consistency.

On 0.95 at least (not their latest version admittedly), here's what I get:

$ mkdir renametest
$ cd renametest
$ hg init .
$ mkdir dir1
$ echo hello > dir1/greeting
$ hg add
adding dir1/greeting
$ hg commit -m "create dir1"
$ hg mv dir1 dir2
copying dir1/greeting to dir2/greeting
removing dir1/greeting
$ hg st
A dir2/greeting
R dir1/greeting

So A=add & R=remove => hg 0.95 is tracking a dir rename as a series of
deletes and a series of adds.

A more important test is to clone a branch, rename some directories in
one of the branches and add files to the original directory in the
other, and try merging. Do files get put into the right places? In
Bazaar they do while in earlier versions (at least) of hg they don't.

Perhaps these things are fixed in hg now? I certainly hope so. If not,
then it sounds like the Bazaar and Hg communities have different
interpretations w.r.t. what "renaming is fixed" means.

Ian C.
AUVRAY Sebastien
2008-05-14 19:29:02 UTC
Permalink
Hi Ian,

With:
*cd mozilla.bzr
bzr clone master my-fix*
I get better times: 117sec, which is nearly twice faster than without shared
repository but still a lot higher than competitors.
Finally concerning renaming you're right that hg do not track them (this was
in my article). Your test brings same result on v1.0 (and is no "error"
btw).
Concerning the other test, i did play the test (
http://automatthias.wordpress.com/2007/06/07/directory-renaming-in-scm/)
before doing my article which hg passed successfully.

Regards,
Sébastien.

On Tue, May 13, 2008 at 2:24 AM, Ian Clatworthy <
Post by Ian Clatworthy
Post by AUVRAY Sebastien
Hi Ian,
Sorry for my late answer, I was away.
Your feed back is very much appreciated. I just did a first update of
the article accordingly (also with the comments I saw around). Actually
I wanted to send the article to the three vcs maintainers, but I guess I
would have had to remodel everything again, then new versions are out,
new features, updates needed, benchmarks needs to be replayed (infinite
loop)... It's been already a lot of time to gather all this piece of
information, reading, playing with the three, chatting, and doing those
benchmarks (I had this article idea since February...).
Concerning your request & feedback.
- You'll find the exact git / hg / bzr repositories I used available at
http://seb.auvray.free.fr/dvcs-bench-repo/. I applied the dummy diff (on
|dom/src/base/nsDOMClassInfo.cpp|) you'll find at the end of this mail*.
Thanks.
Post by AUVRAY Sebastien
|||bzr clone mozilla.bzr/master/|
Some remarks: I know /clone/ is no bzr command but an alias for
/branch/. What I wanted to test was the basic cloning (> /xxx clone a
b/) without the network protocol overhead (in case /a/ would be http://
...)
Right. It's a worthwhile test as it's a common operation. The bzr
repository I sent you is already set up as a shared repo. To test
cd mozilla.bzr
bzr clone master my-fix
This will be much faster than cloning outside the shared repo.
Post by AUVRAY Sebastien
Concerning the BzrVs* pages, I find them definitely useful and you guys
in the business are the ones who can best compare each other (knowing
implementations, details, ...). But from the answers from Mercurial we
could see it was biased (model chosen critics, implementation choice...)
and not always up-to-date (renaming for hg is fixed (still not for git),
hg has certainly made some improvements to renaming support but, AFAIK,
it still doesn't track directories as first class objects and therefore
doesn't handle their renaming as well as Bazaar does. This isn't just an
implementation choice - it impacts the UI and model consistency.
$ mkdir renametest
$ cd renametest
$ hg init .
$ mkdir dir1
$ echo hello > dir1/greeting
$ hg add
adding dir1/greeting
$ hg commit -m "create dir1"
$ hg mv dir1 dir2
copying dir1/greeting to dir2/greeting
removing dir1/greeting
$ hg st
A dir2/greeting
R dir1/greeting
So A=add & R=remove => hg 0.95 is tracking a dir rename as a series of
deletes and a series of adds.
A more important test is to clone a branch, rename some directories in
one of the branches and add files to the original directory in the
other, and try merging. Do files get put into the right places? In
Bazaar they do while in earlier versions (at least) of hg they don't.
Perhaps these things are fixed in hg now? I certainly hope so. If not,
then it sounds like the Bazaar and Hg communities have different
interpretations w.r.t. what "renaming is fixed" means.
Ian C.
Ian Clatworthy
2008-05-15 00:19:24 UTC
Permalink
Post by AUVRAY Sebastien
Hi Ian,
/cd mozilla.bzr
bzr clone master my-fix/
I get better times: 117sec, which is nearly twice faster than without
shared repository but still a lot higher than competitors.
OK. Could you please update your graph (and supporting data) in your
article accordingly?

Given the slowness you're seeing vs my earlier benchmarks, I'm guessing
we're slowing down badly in this case as history grows. This may well be
because we validate everything as we create a new branch. In Bazaar,
clone is more than just "copy" - it also prevents any corruptions in the
source being propagated.

While we don't openly document it, you can always use 'cp -a' to clone a
Bazaar branch inside a shared repository. Because of our storage
architecture (where the revisions are stored in the shared repo), this
is space efficient (without the need for hardlinking).

Anyhow, thanks for the updated measurement. I'll raise a bug about this
issue.

Ian C.
Jelmer Vernooij
2008-05-15 00:59:11 UTC
Permalink
Post by Ian Clatworthy
Post by AUVRAY Sebastien
Hi Ian,
With: /cd mozilla.bzr bzr clone master my-fix/ I get better
times: 117sec, which is nearly twice faster than without shared
repository but still a lot higher than competitors.
OK. Could you please update your graph (and supporting data) in
your article accordingly?
Given the slowness you're seeing vs my earlier benchmarks, I'm
guessing we're slowing down badly in this case as history grows.
This may well be because we validate everything as we create a new
branch. In Bazaar, clone is more than just "copy" - it also
prevents any corruptions in the source being propagated.
While we don't openly document it, you can always use 'cp -a' to
clone a Bazaar branch inside a shared repository. Because of our
storage architecture (where the revisions are stored in the shared
repo), this is space efficient (without the need for hardlinking).
Anyhow, thanks for the updated measurement. I'll raise a bug about
this issue.
I wonder if we should have a "benchmark mode", i.e. some flag you can
set to say "I want performance, not correctness" that would turn off
some of this checking. git and mercurial seem to prefer performance in
most cases and allow extra options for extra correctness (checking).
I.e. you can check the repository manually after it's been copied with
git/mercurial. Another example I ran into a while ago:
http://jelmer.vernstok.nl/blog/archives/216-Git-cutting-corners.html

Maybe --turbo? :-)

Cheers,

Jelmer
Martin Pool
2008-05-19 00:55:41 UTC
Permalink
Post by Jelmer Vernooij
I wonder if we should have a "benchmark mode", i.e. some flag you can
set to say "I want performance, not correctness" that would turn off
some of this checking. git and mercurial seem to prefer performance in
most cases and allow extra options for extra correctness (checking).
If there's some check or secondary operation that turns out to be
expensive then I'd agree we should make it optional. I don't think
--benchmark is such a good idea, because if it's done properly it may
be useful in non-benchmark situations, and also people actually
_doing_ benchmarks may be reluctant to turn it on if it is not
generally used. Having added the option we can look at whether it
should be on by default.

I certainly added some unnecessary checking code in the early
releases. I would distinguish between 'correctness' (which we always
strive for) and 'checking' (which should be mostly unnecessary if
you're sure you're correct.) Rather than always checking things
implicitly, we can look at: instead adding a test that runs the code
then does the check; a separate check operation; an option to turn on
checking.
Ian Clatworthy
2008-05-23 13:00:13 UTC
Permalink
Post by AUVRAY Sebastien
Hi Ian,
/cd mozilla.bzr
bzr clone master my-fix/
I get better times: 117sec, which is nearly twice faster than without
shared repository but still a lot higher than competitors.
That really is strange. I've downloaded the various repositories
you used and tested out the bzr and hg ones at least. I noticed
that the Bazaar one wasn't packed so I did that and cleared out
obsolete packs. (fastimport does that implicitly now but it didn't
when you ran it.) That put bzr further ahead of the others in
storage efficiency btw.

The very first time I ran clone, both Bzr and Hg took over a minute
with Hg being quicker. Running the benchmark a few times though,
I get repeatable numbers:

* bzr 1.5+ - 22 secs
* hg 0.95 - 26 secs

Now these aren't the versions you tested but the Hg figure
is close to yours and I don't think bzr has changed much in this
area recently.

Anyhow, I've raised a bug for this to track it. See
https://bugs.launchpad.net/bzr/+bug/230567. I've also
released a patch today that speeds up bzr further - taking
it down to 16 seconds. If that patch gets approved, it should
be available in Bazaar 1.6, 2-3 weeks from now. See
http://bundlebuggy.aaronbentley.com/request/%3C4836BC78.2030109%40internode.on.net%3E.

If you have any additional thoughts on why bzr is giving you
such a different number from what I'm seeing, please let me know.

Ian C.
AUVRAY Sebastien
2008-05-24 09:17:40 UTC
Permalink
Hi Ian,
Sorry I am away until end of May.
Will look at this asap (beg. June).
By the way for my tests I got also this 1st try >1minute (but get rid
of best and worst case so that wouldn't appear in the average).
Concerning the pack if you could give me access to the clean repo you
did, thanks.
Sebastien
Post by Ian Clatworthy
Post by AUVRAY Sebastien
Hi Ian,
/cd mozilla.bzr
bzr clone master my-fix/
I get better times: 117sec, which is nearly twice faster than without
shared repository but still a lot higher than competitors.
That really is strange. I've downloaded the various repositories
you used and tested out the bzr and hg ones at least. I noticed
that the Bazaar one wasn't packed so I did that and cleared out
obsolete packs. (fastimport does that implicitly now but it didn't
when you ran it.) That put bzr further ahead of the others in
storage efficiency btw.
The very first time I ran clone, both Bzr and Hg took over a minute
with Hg being quicker. Running the benchmark a few times though,
* bzr 1.5+ - 22 secs
* hg 0.95 - 26 secs
Now these aren't the versions you tested but the Hg figure
is close to yours and I don't think bzr has changed much in this
area recently.
Anyhow, I've raised a bug for this to track it. See
https://bugs.launchpad.net/bzr/+bug/230567. I've also
released a patch today that speeds up bzr further - taking
it down to 16 seconds. If that patch gets approved, it should
be available in Bazaar 1.6, 2-3 weeks from now. See
http://bundlebuggy.aaronbentley.com/request/%3C4836BC78.2030109%40internode.on.net%3E.
If you have any additional thoughts on why bzr is giving you
such a different number from what I'm seeing, please let me know.
Ian C.
Ian Clatworthy
2008-05-30 07:07:44 UTC
Permalink
Post by AUVRAY Sebastien
Hi Ian,
Sorry I am away until end of May.
Will look at this asap (beg. June).
By the way for my tests I got also this 1st try >1minute (but get rid
of best and worst case so that wouldn't appear in the average).
Concerning the pack if you could give me access to the clean repo you
did, thanks.
Hi Sebastien,

I've run the latest bzr-fastimport (rev 76) and uploaded the repository
to http://people.ubuntu.com/~ianc/benchmarks/repos/bzr/mozilla-repo.bzr.tar.bz2.

As well as packing the repository on completion, that version of
fastimport fixes some unicode encoding bugs, i.e. some author/committer
names and commit messages will now display correctly. Otherwise, it
ought to be pretty much the same as the one provided previously.

Ian C.

Matthieu Moy
2008-05-14 19:49:57 UTC
Permalink
Post by Ian Clatworthy
$ mkdir renametest
$ cd renametest
$ hg init .
$ mkdir dir1
$ echo hello > dir1/greeting
$ hg add
adding dir1/greeting
$ hg commit -m "create dir1"
$ hg mv dir1 dir2
copying dir1/greeting to dir2/greeting
removing dir1/greeting
$ hg st
A dir2/greeting
R dir1/greeting
So A=add & R=remove => hg 0.95 is tracking a dir rename as a series of
deletes and a series of adds.
Reading "hg status --help" should help you understand your
miss-understanding.

I like the way bzr deals with renames, and I don't know why -C is not
the default for "hg status", but really, people should read the doc
before trying to compare tools.
Ian Clatworthy
2008-05-15 00:00:13 UTC
Permalink
Post by Matthieu Moy
Post by Ian Clatworthy
So A=add & R=remove => hg 0.95 is tracking a dir rename as a series of
deletes and a series of adds.
Reading "hg status --help" should help you understand your
miss-understanding.
I like the way bzr deals with renames, and I don't know why -C is not
the default for "hg status", but really, people should read the doc
before trying to compare tools.
Matthieu,

Thanks for the tip - adding -C certainly helps and I wasn't aware of it.
After renaming dir2 to dir3, I then get:

$hg st -C
A dir3/greeting
dir2/greeting
R dir2/greeting

which I don't find obvious but --help clarifies the output. FWIW, if I
then commit this change, I'm back to the old output (in 0.95 at least):

$hg ci -m "..."
$hg st -C --rev 1
A dir3/greeting
R dir2/greeting

I'm sure hg's handling of renames is good enough for many - I'm not
suggesting it's broken and it's an improvement on git. I am suggesting
though that it's well short of what Bazaar does in several ways:

1. Reporting via status. Bazaar shows the rename as such (not as a
copy+remove pair) and Bazaar shows directories as renamed (not
each file inside it as changed).

2. Merging after directory renames.

The latter issue is the bigger one I feel.

Ian C.
Loading...