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