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

[Robert Collins]

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? 
Were you using a local cache of any sort, or direct access to a
networked repository?
Explicit or tagline id's ?

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.


>    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.

> 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

>   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).

> > Yup.   In the meantime, you might consider a small-scale consulting
> > gig for one of the experienced arch users.   I would hope that you can
> > find someone on the list who can help you with your evaluation and
> > prospective infrastructure design for a few hundred bucks.
> 
>    Yeah, I think I'd have them write up a:
> 
>     "Getting started with arch for a development group'
> 
>   document for public use, rather then setup our archive in particular.
> 
>   Or, like I said in the bottom of that long mail, have a bunch of 
> higher-level
> scripts that automated things from the use case point of view. It would 
> have to make some
> assumptions that tla doesn't make, but it would make switching to arch 
> easier to do until
> you wanted to do something off the beaten path.

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.

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..

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part