[Gnu-arch-users] Re: arch commit on large trees ?

[Philippe Moutarlier]

Matthieu,

I still had a pristine tree so it was using it. Now things seem ok, but
I would like to understand why I get such big delays there :

baz status 

27 sec 

* looking for address@hidden/router--home--1.0--patch-5 to compare
with

30 sec
 
* comparing to address@hidden/router--home--1.0--patch-5

22 sec

M  src/router/Makefile

It seems that the comparison itself is the fastest part of the process.
Why does it take so long to just start looking for the patch, then for 
starting the comparison ? Do I have an installation probelm here ?

Thanks

Philippe


On Wed, 2005-08-24 at 10:22 +0200, Matthieu Moy wrote:
> "Philippe Moutarlier" <address@hidden> writes:
> 
> > I am confused. I have created the revision library with sparse and
> > greedy options, changed a single line in a single file, and I am 5
> > minutes down my commit still waiting on "update pristine tree ..."
> 
> If it updates your pristine tree, then most probably you didn't
> configure your revision library to be greedy (see library-config).
> 
> > OK , now it is done : 6 minutes for 1 file ?
> 
> 1 file or all the files in your tree do not change much. Commit means
> "compute all the changes in the working directory, and upload this
> changeset". For that, arch needs a reference tree (it can be a
> pristine, ie in your working tree, or in the revision library).
> 
> > I know I can commit a single file separately, but what about a
> > directory ? It took 10 minutes to add 10 files and commit.
> 
> Probably most of the time was spent building the reference tree. This
> is done by copying the closest reference tree available, and applying
> changesets from the archive to build the new one. The first time,
> you'll start with base-0, and apply all changesets up to patch-N
> (latest revision). But if you have a greedy revision library, then
> next time, you'll already have patch-N, and you'll want to build
> patch-(N+1), which is much faster.
> 
> In baz 1.5 (the development version, but it's quite stable actually),
> the reference tree for patch-(N+1) is built automatically when you
> commit after patch-N, so, doing
> 
>   baz status
>   baz commit
>   baz status
>   baz commit
>   baz status
> 
> will need to build the reference tree for the first "baz status", and
> then, only "baz commit" will need access to the archive, and only to
> upload the changeset. Surprisingly, you never read anything from the
> archive, and "baz status" can be a disconnected operation.
> 
> > Does arch scale up to big projects with this patch applying mechanism ?
> 
> I've never used it for "big" projects, but have a look at
> http://arch.ubuntu.com/ if you want to have an idea of how bazaar
> is used in a big organization.
> 
> Emacs development partly uses Arch for its development. "baz status"
> in the Emacs tree takes 3.1 seconds on my machine (2358 source files).
> Commit is a bit longer that status, but not much. Most of the time is
> spent in the changeset computation.
>