Meaning of "HEAD" with complex branching

[Jean-Marc Saffroy]

Hello,

I'm currently working on setting up a CVS repository for an internal 
project, and I plan to have several active branches.

That is, we integrate vendor releases, they can be 1.x, 1.y (y > x) or 2.z 
for instance. Say we first import 1.x (initial import), then 2.z (in CVS 
we root it on 1.x), finally 1.y (branch also rooted on 1.x); each time we 
need to add our local patches.

For this, I plan to maintain for each version of the product several (say 
10) branches, one for each local feature we add, and one branch to merge 
them all into a release. Something like:

VENDOR  --+ [1.x] -----------------------+ [2.z] -------------...
BRANCH    |- 1.x-feature-foo             |- 2.z-feature-bar (foo is gone)
          |- 1.x-feature-bar             |- etc.
          |- 1.x-feature-baz
          |- 1.x-merge (here we merge "feature" branches above)
          |
          \-+ [1.y] ----...
            |- 1.y-feature-foo
            |- etc.

Extensive use of tags is planned, so as to merge changes in each feature 
branch only once in the merge branch.

===> The ultimate goal is to be able to easily remove a feature in the 
future (eg. when it is no longer needed, or integrated upstream). Features 
are typically small chunks of code scattered in a couple of files, and 
cannot be coded as some kind of plugin or anything like that.

Of course, this requires merging each feature branch when we receive a new 
release from the vendor, but I suspect it is easier to merge features 
separately to the new tree, then put them all together, rather than all at 
once. Further, developers can work separately on different features, only 
merging to the merge branch requires synchronisation.

Now, my questions:

 * Is "HEAD" what we get from a fresh cvs checkout without any tag?

 * What exactly does it contain? This is sheer curiosity, since in the 
scheme above, *all* chechins/checkouts should relate to a specific branch 
(actually I would not want changes to land to the wrong branch; I don't 
know if it can be enforced?)

 * Do any others have experience with this approach on branching? Is it 
manageable? Any gotchas that come to your mind?

 * Does anybody suggest a different approach to achieve the same goal? I 
find the process above burdensome, but I want to minimise bad surprises in 
the future when trying to remove a feature.


Thanks in advance for your answers.


--
Jean-Marc Saffroy - address@hidden