gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: Paul Hedderly
Subject: Re: [Gnu-arch-users] Why we might use subversion instead of arch.
Date: Tue, 24 Feb 2004 10:38:51 +0000
User-agent: Mutt/1.3.28i

On Fri, Feb 20, 2004 at 12:41:05PM -0700, Pierce T. Wetter III wrote:
>  Oh, yeah, arch is really intriguing. It in many ways seems closer to 
> how we
> actually need to work. Its the learning curve I'm having a problem with.

Yes...

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

you can use: archive/category-subcat--branch--version
or:          archive-cat/subcat--branch--version
or:          archive/category--subcat-branch--version
or:          archive/category--subcat--branch-version

It really is freeform - you just need to set your own policies.

I strongly encourage you to work out how any other SCM (other than
Bitkeeper) will support you with distributed and disconnected users at
all. For remote devs with dialup, tla beats all other open SCMs hands
down.

What you're struggling with, is trying to use tla with a CVS mindset.
And it does take a while to shrug off that mindset.

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

But I do trust HEAD... and I want several things:

        - ability to get any rev quickly. (can use forward/reverse
          patches, but I'll always need patches unless I want to store
          complete revisions. Ouch!)
        - an archive that is SAFE. Now that means an archive where files
          that are stored are never changed. Ever. With the storing of
          HEAD and reverse patches, every commit changes everything in
          the archive... thats slow on the filesystem (for every commit
          rather that on initial get) and risks corruption every time I
          commit
        - easy distributed working. If my stored version and each
          patch/delta is changing every time I commit... and another
          worker in his branched archive is doing the same, when I want
          to merge his work back into mine... where does the SCM start
          trying to decode the differences in the deltas?!

What you say you want is basically CVS. TLA is not CVS and is far, far,
far superior precisely because it does things differently.

Take some time to 'get' tla, and you will not regret it.

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

Please feel free to write that as you learn. Put it on the Wiki and ask for it 
to
be included in the main tla docs. It would help others coming at tla
from CVS mindsets too.

--
Paul




reply via email to

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