[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Meaning of "HEAD" with complex branching

From: Jean-Marc Saffroy
Subject: Meaning of "HEAD" with complex branching
Date: Mon, 6 Dec 2004 21:05:09 +0100 (CET)


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]