[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John A Meinel
Subject: Re: [Gnu-arch-users] Re: arch commit on large trees ?
Date: Tue, 23 Aug 2005 11:59:54 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)

Philippe Moutarlier wrote:
> 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 ..." with
> billions of disk access so I can barely do anything else on my laptop.
> OK , now it is done : 6 minutes for 1 file ? I know I can commit a
> single file separately, but what about a directory ? It took 10 minutes
> to add 10 files and commit.
> Also, after my commit, there is a new revision but it is not added to
> the library. Do I need to add it by hand ?
> Does arch scale up to big projects with this patch applying mechanism ?
> Thanks,
> Philippe

Well, first off, the latest baz code (I'm not sure if it is in 1.4.2,
but it is definitely in 1.5devel) does a lot better about not stat'ing
files over and over, which means it handles larger trees better.

Second, what is the output of "tla my-revision-library", it sounds like
it doesn't recognize that the library is there.

Obviously you have a pristine tree already, and it might be
preferentially updating it, rather than using a revlib. In the working
directory you should have {arch}/++pristine-trees
You can remove ++pristine-trees and everything underneath it. Also, if
you have neighboring working directories with pristine trees for similar
revisions, you might need to delete them as well.

Arch is really designed to have a revision library, but since that is
yet another setup step, it was attempted to work around it, and do the
best it can with pristine trees in working directories.

I think we should just be done with it, and default to having a revision
library. Let people know that they can move it, and that if it isn't
periodically cleaned, it can grow large.

Though, there again, bzr is planning on doing it differently with a
centralized storage. My only qualm with this, is you don't have any idea
what is safe to remove from the central store, since you might have lots
of branches, each which need some set. So if you are done with a branch,
you can't just remove all patches that are present, since some other
branch might want them.

I'm guessing that monotone and git don't really handle the "get rid of
some stuff" (though monotone allows you to setup multiple databases).


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]