[Top][All Lists]

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

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

From: Martin Pool
Subject: [Gnu-arch-users] Re: Why we might use subversion instead of arch.
Date: Thu, 04 Mar 2004 16:00:08 +1100
User-agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity. (Debian GNU/Linux))

On Fri, 20 Feb 2004 16:45:54 -0700, Pierce T. Wetter III wrote:

>    I'm definitely in culture shock which is why I posted. As I said,
> and the FAQs say, some documentation explaining that "new take on
> things" would help quite a bit.

>    I'm still not really sure I grok arch, and blah--blah--blah isn't
> really helping...

>    My issue right now is that any development process needs to decide 
> where "truth" lives.

>    In CVS land, that is HEAD, from the central server. In our case,
> we use CVS with a pretty simple model, because revision numbers are
> meaningless for us. There's what's deployed, and there's what's in
> development. Periodically, development gets deployed.

>    In arch land, you have to decide where truth lives. There's also
> explicit provision for versions, which ends up confusing me, because
> I'm not used to thinking about versions.

I think with arch, as with any powerful tool, there is a risk of
reading the manual and then going to try out all the cool features in
your first project.  (I think I tried operator overloading in my first
C++ program... (please no C++ flamewar.))

You didn't say much about your own project, but it's possible that it
is an in-house project which does not release public revisions as,
say, tla or the linux kernel does.  You don't think of yourself as
"working on v1.2", you're just working on it.

In that case, I'd say, just don't use versions.  Put everything in 


and treat as if there is a single stream of revisions rolling forward,
just like working on a CVS trunk.  (I guess Tom would say to call it
"devo".)  Go ahead and use that just like CVS; even at this basic
level I think it performs better.

The next step might be to make a separate branch for mike's db work,
which needs to merge with main from time to time.  So make
fooix--db--0 as a tag, and then star-merge as the tutorial says.


reply via email to

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