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

[Philippe Moutarlier]

>$ tla my-revision-library

/usr/home/philippe/tla-rev-library/

I know that the system knows about the library because I could do a 
tla library-add of a specific revision with no problem.

I am not sure I understand the "centralized" notion of rev libraries in
the context of decentralized development. What I want to get is a
(easy .?) way to maintain a "mobile" branch of a project that I can
merge every once in a while with other branches of the same project.
This what I am trying now. I branched a project on my laptop and try to
modify/commit on it. This what takes so long.
    
Then I need to maintain my mobile, decentralized, rev lib, right ?

Also, I am using tla, should I try bazaar instead ? Any major
differences ?

Thanks,

Philippe


On Tue, 2005-08-23 at 11:59 -0500, John A Meinel wrote:
> 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).
> 
> John
> =:->
>