[Gnu-arch-users] Re: Question about branching a subset

[Andrew Wilcox]

> I have to implement a versioning system for my company, but the
> problem is that there are very many files involved.

First question is: is this actually a problem in practice?  Computers
have lots of disk space.  Arch is fast and efficient, and is superfast
when used with revision libraries and hard linking.

And, once a developer or a tester has fetched your entire tree,
updates are done incrementally.  Getting the entire tree the first
time might be slower, but updates are still fast.

So the first thing I'd try is to put everything into an archive, and
see if it worked fast enough for me.

> The structure of the environment works with different layers (one
> for our software vendor, one for customizations FROM our vendor, and
> one for all our own developments). These are also divided into
> subcategories for each site, because not all software is for all
> sites, and a CORE for something that is for all sites.

I'd suggest starting with two arch projects.  (To avoid confusion
around the word "project", I'll use "arch project" to refer to an arch
project tree, and "development project" to refer to your own individual
development projects).

The two arch projects I suggest you consider are:

* one that tracks code from your software vendor
* one for all of your own developments

Then,

* Have a branch off of the software vendor tree to track your
  customizations

* CORE and the the site categories are simple subdirectories within
  the second arch project

* Have separate branches for testing and production

* Have separate branches for each individual development project

> Furthermore, for every site there is a production and
> test-environment. The test-environment only contains software that
> is in test, when it is OK, it will be removed from test and put into
> production.  The test environments also look in the production
> environment for all object-files it hasn't itself.

This sounds like something I would do if I didn't have a version
control system yet.  But life is simpler with a version control system
like arch.

Do your development in an individual development project branch.

When you think the development project is ready, merge those changes
into a testing branch.

When the changes have passed testing, merge those changes into your
main production branch.

All within the *same* arch project.

> I came up with the idea to work with little projects. Develop in a
> project, copy source from the destination environment, or create
> new. Then, when finished, it must be delivered to test. Sometimes
> there must be more changes after testing, so it must be redelivered to
> test. When testing completes, it will be delivered to prod.

Yes, "working with little projects" is an excellent approach.  And you
can have a branch for each and every little project.  Branches in arch
are cheap and easy.  It costs nothing to have lots of them.


So why do I suggest having two arch projects, not one, or not many?

I notice that there's a tendency among people new to version control
to think of putting everything in different arch projects, or
"repositories" as they're called in CVS.  "We have this library and
this core code and these different things we're working on and let's put
them all into different arch projects (or repositories)".

Unless there's a *reason* that you *need* to put things into different
arch projects, I suggest putting everything into a *single* arch
project.  Fetching, commiting, branching, merging, everything in arch
is simple with one arch project.

One area where you will most likely need more than one arch project is
when you have code crossing organizational boundaries.  You're
tracking code written by your software vendor, and it is much easier
to track a non-arch project when you have an arch project which is
dedicated to that one task, and is doing nothing else.  Then your own
customizations can easily and naturally be put in a branch off of the
arch project containing the software vendor code.

I hope this helps,

Andrew Wilcox