Info Q article on DVCS - a request and some feedback

[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.
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 <
ian.clatworthy at canonical.com> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080514/a4db67f9/attachment.htm