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

[Charles Duffy]

This thread has gotten pretty long already, but I missed big chunks of
it, including this one for a while (my spam filter flagged it for some
reason). Here I'm revising/clarifying some of my suggestions based on
actually having useful context to put the discussion in. Hopefully I'm
not being entirely redundant or wrongheaded.

On Fri, 2004-02-20 at 11:45, Pierce T.Wetter III wrote:
>      Everytime we code freeze for deployment, we copy "blessed" to 
> "deployment".

Right; the tla "tag" command will DTRT here.

>      When developers have changes, they merge them into the "deployment" 
> repository if they're bug fixes for the deployment, along with 
> "blessed" so that there is a local copy. This is really the same thing 
> as a deployment branch, but conceptually it seems easier, and it would 
> avoid problems we have where separate archives?fixes don't quite make it into 
> the 
> deployment build.

If not all your customers have the same version, you might want to
consider tagging off branches (or even versions, if you use them) to tie
bugfixes to the deployment version they apply to; that way you don't
have issues along the lines of "we want all the bugfixes for this
customer's outdated version, but none of the new features since moved
into the deployment branch from dev".

>      If two engineers need to work together, like if "batch_guy" needs 
> to work with "incremental_guy", no one else has to be involved, they 
> can just merge their changes together.

Right.

>      Since we have a system of servers, clients, etc. most developers 
> end up having several machines they have to keep in sync. With arch, 
> your local test server could check out from your personal repository.

Right -- and you'd probably want your personal repository to be local 
itself, too.

>   How we would have to setup:
> 
>    Well, first, every developer would end up needing to have a network 
> accessible "master" archive.

Pretty much -- but that's not to say that developers' archives need to
sit on a central server. As long as you have a shared filesystem (NFS
shares of developers' homedirs off their workstations?) _or_ if all
developers have access to other developers' workstations via the OpenSSH
sftp subsystem, developers' own archives can stay on their workstations,
with merges going into the master archive when they see fit to request
one. This makes a lot of sense in terms of performance.

It might make sense to _mirror_ developers' archives onto the central
web server on a regular basis, though -- or even onto one web server on
each of your sites; this'll both provide backups for developers'
archives and decrease the need for traffic to different offices.

> Since arch doesn't have any concept of a 
> server process, that means setting up a web dav server with multiple 
> subfolders:
> 
>     /archrepositories/incremental_guy
>     /archrepositories/batch_guy
>     /archrepositories/blessed
>     /archrepositories/development
> 
>   Predominantly, mostly developers would use the 
> /archrepositories/development repository as "truth". You'd only need 
> your "personal" archive if you needed to work with someone else 
> independently of the archive.

Why have all these separate archives? It's perfectly to reasonable to
have a single archive with multiple branches:

$OFFICIAL_ARCHIVE/myproject--development--1.0 ## doesn't break the build
$OFFICIAL_ARCHIVE/myproject--qa-approved--1.0 ## QA likes it
$OFFICIAL_ARCHIVE/myproject--deployment--1.0 ## actually in the field
 ...and so forth (presumably with different version numbers at least in
the deployment branch if that makes sense for you).

As for the individual developers, as long as they're keeping their own
branches on their own workstations (presuming said workstations are
sftp-accessible, again), their archives can be something like this:

$INCREMENTAL_GUY_ARCHIVE/myproject--development--1.0
$BATCH_GUY_ARCHIVE/myproject--development--1.0

So pretty much, you just create the _one_ archive on your webdav server
(or any box that has space accessible to everyone who needs it via ssh),
teach each developer to create their own archives, and everything Just
Works.


On the matter of checking in directly to the --development archive, you
can do it, but it's a bit of a break from what typically works well for
most of the people here: The Arch Way process-wise is to keep your own
tree up-to-date with the development branch (star-merge from it
frequently), make changes in your own personal tree, and then when
you're happy with something (or at least it doesn't break stuff) merge
it into the --development branch. tla-pqm can do things like enforcing
that the code that's merged into --development actually compiles and
passes whatever automated test cases you have handy, whereas developers'
personal archives can be allowed to be broken (such that developers can
break changes which temporarily break the tree into multiple commits to
their local archive, yet never break the whole tree as they merge all
those multiple commits into the --development branch in one big chunk).


Something to think about, anyhow.