Moving to bzr?

[Dhruva Krishnamurthy-2]

Hi,
 Not trying to start a flame thread, however I would like to update
some findings.
I am updating bzr from their development branch and hence have the
latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
is running for >15 mins versus less than 3 mins for git. This is a
serious usability issue. If more constructive feedback is required, I
could profile it send the output over time and see if things are
improving or status quo.

-dhruva

--
Contents reflect my personal views only!

[Christian Faulhammer-6]

Hi,

dhruva <dhruvakm@...>:
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git. This is a
> serious usability issue. If more constructive feedback is required, I
> could profile it send the output over time and see if things are
> improving or status quo.

 I do share your current observations, though I sync regularly and I
always had a ration of 1:2 (Git 1.6.0.4 to Bzr 1.10) up to now.  So I
assume this is not a systematic issue but depending on the delivering
machine.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[davidswelt]

On 4 Jan 2009, at 07:42, dhruva wrote:

> Not trying to start a flame thread, however I would like to update
> some findings.
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git. This is a
> serious usability issue. If more constructive feedback is required, I
> could profile it send the output over time and see if things are
> improving or status quo.

On a related note, I found similar delays with "log" and "log --short"  
with a branch stacked on the Emacs repo.
(Reported here: https://bugs.launchpad.net/bzr/+bug/309374)

To sum up, bzr log on a file from the Emacs repository (but on the  
stacked branch sitting in between) takes 1min20; "log --short" still  
takes 35sec.

This is with Bzr release 1.10, the latest repository formats (both for  
Emacs and for the stacked branch).

[Karl Fogel-6]

dhruva <dhruvakm@...> writes:
>  Not trying to start a flame thread, however I would like to update
> some findings.
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git. This is a
> serious usability issue. If more constructive feedback is required, I
> could profile it send the output over time and see if things are
> improving or status quo.

I'd like to know the details, and try to reproduce.  What are the exact
repository addresses you're pulling from?  Are you getting approximately
the same number of revisions in each pull?

Thanks,
-Karl

[Eli Zaretskii]

> Date: Sun, 4 Jan 2009 18:12:00 +0530
> From: dhruva <dhruvakm@...>
>
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git.

Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
command to resync with the master repository?  Because if it is, it is
slower than CVS by a large margin (but so is git's 3 min, so I assume
"bzr pull" is not the equivalent of "cvs up -d").

[Tassilo Horn-5]

dhruva <dhruvakm@...> writes:

Hi,

> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git.

Currently I don't follow the bzr repo, but use the git mirror.  But I
never got a pull that's longer than 20 seconds.  For example the pull I
did a minute ago fetching all changes between January first and now took
13 seconds.

I use the mirror at git://git.sv.gnu.org/emacs.git.

Bye,
Tassilo

[Richard Stallman]

    I am updating bzr from their development branch and hence have the
    latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
    is running for >15 mins versus less than 3 mins for git.

How about sending a _precise_ bug report to the bzr maintainers?

[Stephen J. Turnbull-2]

Eli Zaretskii writes:

 > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
 > command to resync with the master repository?  Because if it is, it is
 > slower than CVS by a large margin (but so is git's 3 min, so I assume
 > "bzr pull" is not the equivalent of "cvs up -d").

Are you testing on Windows?  git has historically had performance
problems on Windows because its Unix-oriented optimizations are often
pessimizations on Windows.  Like other posters, I've never seen a git
pull longer than 30 seconds (Mac OS X) or 15(!) on GNU/Linux, some of
which updated more than 100 objects (maybe nearly 1000) because I
don't do it often.

In terms of effect on the working directory, "bzr pull" is indeed the
equivalent of cvs up -d, but the implementation is quite different.

I believe that there are important improvements to pull that will be
in bzr 1.11 or 1.12 (so within two months), but they may require a
repo format upgrade.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@...>
> Cc: dhruva <dhruvakm@...>,
>     emacs-devel@...
> Date: Mon, 05 Jan 2009 12:50:51 +0900
>
> Eli Zaretskii writes:
>
>  > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
>  > command to resync with the master repository?  Because if it is, it is
>  > slower than CVS by a large margin (but so is git's 3 min, so I assume
>  > "bzr pull" is not the equivalent of "cvs up -d").
>
> Are you testing on Windows?  git has historically had performance
> problems on Windows because its Unix-oriented optimizations are often
> pessimizations on Windows.

No, I didn't mean to say that git is slow _for_me_.  I was referring
to the git performance numbers by the OP:

> > I am updating bzr from their development branch and hence have the
> > latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> > is running for >15 mins versus less than 3 mins for git. This is a
                                   ^^^^^^^^^^^^^^^^^^^^^^^^
"Less than 3 mins" is too slow, if what I've heard about git is
correct.  Maybe the OP was testing that on Windows.

[Dhruva Krishnamurthy-2]

Hello,

On Mon, Jan 5, 2009 at 9:50 AM, Eli Zaretskii <eliz@...> wrote:
> to the git performance numbers by the OP:
>
>> > I am updating bzr from their development branch and hence have the
>> > latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
>> > is running for >15 mins versus less than 3 mins for git. This is a
>                                   ^^^^^^^^^^^^^^^^^^^^^^^^
> "Less than 3 mins" is too slow, if what I've heard about git is
> correct.  Maybe the OP was testing that on Windows.

My git timings were not scientific. Please do not use it verbatim. It
was used to just show the difference as a factor. git is fastest
followed by hg, based on repeated tests I have done. I am not testing
CVS because feature wise, CVS does not fall into dVCS category.

Just a thought: Since hg is supported by Savannah, why not Emacs enjoy
a hg mirror on Savannah? Should not take too much effort to set it up.

I would love another GNU package (bzr) serve all of GNU development
but IMHO, it is quite far from being there.

-dhruva

--
Contents reflect my personal views only!

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > No, I didn't mean to say that git is slow _for_me_.  I was referring
 > to the git performance numbers by the OP:

OK.  The OP is Dhruva, so I suppose it is indeed on Windows.

I don't think comparison to CVS or Subversion update is relevant,
because in a DVCS a slow pull does not obstruct work (unless you've
seen a feature on emacs-devel that you're just dying to have).  You
just don't bother with it, do your work, commit, pull upstream when
you have time or the network comes back up etc, and merge.  YMMV, but
I think that is the prevailing opinion.

[Lennart Borgman (gmail)]

On Mon, Jan 5, 2009 at 4:50 AM, Stephen J. Turnbull
<turnbull@...> wrote:

> Eli Zaretskii writes:
>
>  > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
>  > command to resync with the master repository?  Because if it is, it is
>  > slower than CVS by a large margin (but so is git's 3 min, so I assume
>  > "bzr pull" is not the equivalent of "cvs up -d").
>
> Are you testing on Windows?  git has historically had performance
> problems on Windows because its Unix-oriented optimizations are often
> pessimizations on Windows.

Does this mean bzr is unusable for w32 users (for a large project like Emacs)?

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Does this mean bzr is unusable for w32 users (for a large project
 > like Emacs)?

I have no opinion on that.  You'll have to try it yourself.  I don't
use Windows, I'm just relaying or commenting on benchmark information
reported by reliable people.  Whether bzr is usable or not will depend
heavily on whether your usage requires slow operations very often.

I post because I have spent a lot of time evaluating DVCSes (for
XEmacs in autumn 2007, for ESR's book project -- currently stalled --
in December 2007, and now for the Python DVCS PEP (I'm responsible for
git information).  It seems a shame to have emacs-devel go around in
circles if I can contribute useful information.

I use git daily (with so few complaints that I've never bothered to
subscribe to the ML), also hg (which I don't like as much), and stay
in touch with their recent documentation.  They are high performance
and in my usage the UIs are very stable, so I don't follow the mailing
lists much.

I do participate in the Darcs and Bazaar mailing lists (reading them
on a daily basis), also GNU Arch (which is basically asleep).  While I
know that Stefan is occasionally visible on the Bazaar list, as is
Karl Fogel, they don't seem to be as well-informed (or maybe they just
don't have time to post about it here).

FWIW YMMV.

[Dhruva Krishnamurthy-2]

Hello,

On Mon, Jan 5, 2009 at 3:18 PM, Lennart Borgman
<lennart.borgman@...> wrote:

> On Mon, Jan 5, 2009 at 4:50 AM, Stephen J. Turnbull
> <turnbull@...> wrote:
>> Eli Zaretskii writes:
>>
>>  > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
>>  > command to resync with the master repository?  Because if it is, it is
>>  > slower than CVS by a large margin (but so is git's 3 min, so I assume
>>  > "bzr pull" is not the equivalent of "cvs up -d").
>>
>> Are you testing on Windows?  git has historically had performance
>> problems on Windows because its Unix-oriented optimizations are often
>> pessimizations on Windows.
>
> Does this mean bzr is unusable for w32 users (for a large project like Emacs)?

I think Stephen was commenting on m$ port of git. I have been using
MSYS port of git for doing my official work and pull emacs. I have
never had any problems (and hence unsubscribed myself from their
mailing list). However, I remember one posting on #git about msys port
of git not able to support very large repositories (in gigabytes) and
emacs is far from that. The cygwin port does not have any such issues
I was told. So, between cygwin and msys port, you are all set to use a
working and usable git for serious work. One missing feature in msys
git is ability to run the git daemon server, cygwin supports that.

I am going to collect the output of 'timeit bzr.bat pull' which is
equivalent of 'time bzr pull' and post the results somewhere on the
web (need to figure out).

Also, I have a pretty high end laptop (IBM Thinkpad T61 with Intel Duo
(dual core) and 2GB RAM. It is not loaded as I do all my development
using a putty terminal connected to a GNU/Linux box. So, resource is
not an issue.

The sample output of 'timeit bzr.bat pull' looks like this:

Using saved parent location: http://bzr.notengoamigos.org/emacs/trunk/
Now on revision 95263.

Version Number:   Windows NT 5.1 (Build 2600)
Exit Time:        4:53 pm, Monday, January 5 2009
Elapsed Time:     0:04:59.984
Process Time:     0:00:00.046
System Calls:     6639636
Context Switches: 1925320
Page Faults:      299443
Bytes Read:       185970981
Bytes Written:    25746978
Bytes Other:      2649061

From:
95262 lektu     2009-01-05
      Fix typos.
Current:
95263 gm        2009-01-05
      Add 2009 to copyright years.

So, it was 1 change set! The memory usage was high too (I have not
logged it now). I can get perfmon logs for better analysis if
required.

Now, git (pulls and updates the local folder too) with all branches:

From:
commit 7b8942ecec62129282ab75ca8bc009618ec34124
Author: Glenn Morris <rgm@...>
Date:   Thu Dec 18 03:34:16 2008 +0000

    Fix reStructuredText funky capitalization.

To:
commit 5b9823795d0ec55a7a114f9fed93f773a8546908
Author: Martin Rudalics <rudalics@...>
Date:   Mon Jan 5 10:29:41 2009 +0000

    (x_set_frame_parameters): Make sure height (width) get
    applied when fullwidth (fullheight) is set.  (Bug#1522)

Version Number:   Windows NT 5.1 (Build 2600)
Exit Time:        5:04 pm, Monday, January 5 2009
Elapsed Time:     0:03:11.531
Process Time:     0:00:00.031
System Calls:     4480504
Context Switches: 1324154
Page Faults:      508523
Bytes Read:       565680562
Bytes Written:    102819912
Bytes Other:      1241955

I will start posting the details and hope it helps in deciding using
more scientific approach.

-dhruva

--
Contents reflect my personal views only!

[Nick Roberts]

 > I will start posting the details and hope it helps in deciding using
 > more scientific approach.

Please don't.  RMS has stated on several occasions that the choice of VCS for
Emacs development has been decided in favour of bzr i.e it's not up for
discussion.

If I want to find out about the performance of bzr I'll subscribe to the Bazaar
mailing list which would, perhaps, be a more appropriate place to report your
findings

--
Nick                                           http://www.inet.net.nz/~nickrob

[Lennart Borgman (gmail)]

On Mon, Jan 5, 2009 at 1:14 PM, Nick Roberts <nickrob@...> wrote:
>
>  > I will start posting the details and hope it helps in deciding using
>  > more scientific approach.
>
> Please don't.  RMS has stated on several occasions that the choice of VCS for
> Emacs development has been decided in favour of bzr i.e it's not up for
> discussion.

I think it is still interesting to know the performance for bzr on w32
for a project like Emacs.

[Dhruva Krishnamurthy-2]

Hello,

On Mon, Jan 5, 2009 at 5:44 PM, Nick Roberts <nickrob@...> wrote:
>
>  > I will start posting the details and hope it helps in deciding using
>  > more scientific approach.
>
> Please don't.  RMS has stated on several occasions that the choice of VCS for
> Emacs development has been decided in favour of bzr i.e it's not up for
> discussion.

Well, if it has been decided to use bzr, why are not creating a mirror
on savannah. The same way we have git, we could have a CVS mirror
setup on savannah. The server used for git/cvs/bzr will be same (from
same pool) and we can eliminate network related issues. Once the
performance of bzr is found favorable enough, flip the switch to make
bzr primary and cvs as a mirror of bzr repo. I am not trying start a
discussion on VCS afresh but looking forward to putting an end by
having some official dVCS. I would like to ideally use one dVCS for my
official work and private hacking. I prefer to use what Emacs uses in
the long run and develop some expertise in that area.

Regarding posting the performance results, I will post it on a website
and just send a link to it once on this list, do not worry about me
adding extra bytes to the mailing list :)

-dhruva

--
Contents reflect my personal views only!

[Karl Fogel-2]

"Stephen J. Turnbull" <stephen@...> writes:
> I do participate in the Darcs and Bazaar mailing lists (reading them
> on a daily basis), also GNU Arch (which is basically asleep).  While I
> know that Stefan is occasionally visible on the Bazaar list, as is
> Karl Fogel, they don't seem to be as well-informed (or maybe they just
> don't have time to post about it here).

No, I'm a bzr newbie (I very much want to see Emacs switch, though).

[Stefan Monnier]

> I don't think comparison to CVS or Subversion update is relevant,

In the context of whether or not to switch from CVS to Bzr, it is the
only relevant comparison.


        Stefan

[Chetan Pandya-2]

Since this discussion still seems to be ongoing, do I take it to mean that there is some flexibility on this issue?

So far the discussion seems to be focussed on performance issues and the convenience as per individual preferences. It looks like even if there may be slowness for the initial setup, it is not an ongoing issue, so that does not look like a good deciding factor. Other than that, there are issues of work-flow model and stability, bugs and I do not see much discussion in that regard. having used for a very short time I don't think I can add anything there. I liked to hearing people with their own experiences.

Using a tool may be one way of resolving issues with the it rather than that being the deciding factor.

Any idea where things stand?

Chetan
--- On Mon, 1/5/09, Stefan Monnier <monnier@...> wrote:

> > I don't think comparison to CVS or Subversion update is relevant,
>
> In the context of whether or not to switch from CVS to Bzr, it is the
> only relevant comparison.
>
>
>         Stefan