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

[Martin Pool]

On Mon, 23 Feb 2004 14:00:57 -0600, Charles Duffy wrote:

> On Mon, 2004-02-23 at 13:41, Pierce T.Wetter III wrote:
>>    Perhaps the issue was that I don't quite understand how branches work 
>> vs. archives. I thought people were always making archives, but now I'm 
>> starting to think that isn't so true, its just that branches look 
>> similar to making a new archive?
> 
> An archive is a place where you keep branches (where a "branch" is...
> ahh, I almost want to use the "line of development" phrase) a
> category/branch/version combination. Typically folks have fairly few
> archives, often just one, and store a number of different development
> lines within that archive.

Another way to look at is is:

Archives say on what physical disk you want the history to be stored.
Archives are about questions like "do I want this on my laptop so I
can commit on the train", or "do I want this on the central server
where everyone can get it easily" or "do I want this on my end of this
slow dialup line."

A related physical-storage question is that you may need to move to a
different server, or you may want to kind-of-forget about some ancient
revisions, and these are also handled at the archive level.

The category-branch-version thing is more of a "logical" question
about the purpose and destination of the code.  You can imagine that
there is a 'commit criteria' governing each branch, being things like
"documentation fixes", "things going out in 1.2, which should be in
winter", "changes by abc proposed for integration", "things that have
been approved by xyz", "things released to the live server", etc...

When you look at it like this, I think you can see that the two
questions really are orthogonal, and so it is a major feature of arch
that it keeps them orthogonal.  (Unlike almost every other system, as
far as I know.)

> In a commercial environment, it makes sense to have just one official
> central archive, and at least one archive per developer where that
> developer can store their private branches, work-in-progress items, and
> the like.

I think this is the answer for people who say "svn is an easier step
from cvs".  Write some documentation which tells people to create a
single archive and single version and make all their commits to that
common tree, and mention only the commands they need (changes, commit,
update).  Now it is basically as simple as CVS or SVN.  Let people
discover the tricky features when they're ready.

-- 
Martin