Re: [Gnu-arch-users] Why we might use subversion instead of arch.

[Pierce T . Wetter III]

On Feb 20, 2004, at 3:07 PM, Robert Collins wrote:

> On Sat, 2004-02-21 at 06:41, Pierce T.Wetter III wrote:
> > > It does take a little bit of care to set up a tla environment that is
> > > fast but many people have done so successfully.   Once you do so, I
> > > think you'll find many advantages compared to CVS and SVN -- but it
> > > does take some care.
> >
> >    It seemed slow even on the local filesystem.
>
> What version of TLA?

 1.1

> Were you using a local cache of any sort, or direct access to a
> networked repository?

  Everything was local.

> Explicit or tagline id's ?

 Don't know what that means.

> There are some order-of-magnitude reductions in syscalls during tla
> changes coming down the pipeline towards Tom's branch for explicit ids.
> With them, squid, which has ~5K files in a checked out project tree
> takes 3 seconds to do tla changes on my 
> laptop-with-the-slow-hard-drive.

 Sounds like that would help a lot then.
> >    Well, everyone has patches that they have to submit to the master.
>
> arch-pqm is probably the key for you guys. It takes a gpg signed merge
> request, does it, and reports via email. So a commit to the master 
> would
> be something like
>
> commit all changes to be merged
> update your mirror [tla archive-mirror]
> update your project tree [tla update]
> resolve conflicts & commit in your project tree
> send merge request to arch-pqm.

 Ok, I'll look at that.
> > The thing that
> > bothers me about arch is that I'm not sure it would handle our three
> > level deep nesting of
> > projects well. There's this archive/category/project heirarchy, but we
> > really have:
> >   archive/category/sub-category/project.
>
> irrelevant. Archive is a unit of storage, not a unit of organisation
> (although you can pun it as such if you insist.) Not sure what you mean
> by 'project' but in Arch terms a project tree is ~= CVS sandbox.
>
> so we have category--branch--version. i.e. you might do:
> category-subcategory--development--1.1
> category-subcategory--development--1.1

 Basically, I want to be able to treat:

 /Projects/Configuration/server1/

  As a separate project, (we keep our config files under source control)
  While still getting it to checkout as part of the full project tree.

> >   Arch lets me cache if I understand correctly. My objection is more
> > philosophical:
> >
> >    The build source should match some set of files on the repository.
> >
> >   (pretend you don't trust patch. In that case, you'd really like a
> > snapshot of HEAD
> > to always be stored somewhere...)
>
> Thats bogus. Neither CVS nor Bitkeeper, nor RCS store a plaintext copy
> of the leading edge of each branch. AFAIK Arch is the only one that
> allows you to store a full, plaintext copy of a revision. (Thats what a
> cached revision is).

 Good point. Perhaps I just overreacted from seeing "applying patch 7".


> There are already various FAQ's around - my experience has been that
> development groups don't need general stuff that they have to 
> interpret.
> They need interaction with someone that knows the problem space - that
> can rapidly customise Arch to their needs, with a modicum of scripting,
> with appropriate choices of mirror locations, cacheing strategies and
> archive layout.

  Sure, but that person would probably be me...

  So I would decide how it would get setup, then write cheatsheets for 
all the
main use cases.

> Adding another FAQ won't help greatly - becoming users, and giving
> incremental feedback may help us choose appropriate UI tools to reduce
> the learning curve..

  Ok, what FAQs are there besides Tom's tutorial and the wiki?

  Note that the bottom of my original message had lots of feedback, 
which I
haven't seen much comment on yet.

 Pierce