Info Q article on DVCS - a request and some feedback

[Ian Clatworthy]

AUVRAY Sebastien wrote:
> 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.

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

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.

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