[development] CVS branch work best practices?

[Michael Favia]

Bèr Kessels wrote:
> Is there some way, I missed, or misunderstood, or whatever, that allows this 
> process to work without lots of extra work? 
> Is it just me who wants HEAD to be he latest-greatest? 



You are correct in assuming that HEAD should be the destination of all
of your patches and development and that you need to backport those
patches back to all of the branches of the module that you actively
maintain.

There are a couple of solutions to your real and acknowledged problem of
double work and ill mention them concisely along with the general
concerns necessary to keep CVS generally useful as far as the layout is
concerned.

I personally favor the following:

I don't know if this is common but i personally keep a copy of 3 "nodes"
of our drupal CVS tree checked out at all times. These nodes are the
HEAD of core, contrib modules, and contrib themes. As i work on various
projects i "switch the various subfolders of these checkouts to the
appropriate branch for the project that i am working on if it is available.

For instance if i am working on a 5.1 based site i switch it to the
DRUPAL_5 branch for the particular module (not the whole project i
checked out). I as a developer expect that the latest D5 compatible and
"decently stable" version of the module will be available at this
branch. Otherwise i have to introspect each module to see what is its
most recent tag version and that is a pain.

If i find bugs or problems I look at the annotated version history of
the file at HEAD to see if it has been addressed, etc. If not I check
out HEAD and fix the problem and submit the patch. If i'm really
concerned about getting the fix into my branch i add a patch to backport
it as well. Wash rinse repeat. Organizing things any other way creates
all sorts of special criteria as new versions of drupal get branched,
etc. The goal is dependability and consistency without the cost of
double work.

To ease the workload of constantly porting your changes back to previous
branches (D5 and D4.7, etc) I would suggest waiting until you have built
up a number of changes that make creating and applying the "backport
patch" to the branches that are worthwhile. This should probably occur
"at least" a little while before you are planning on tagging a release
of your module. This will give the "more advanced" users of drupal some
time to implement and check everything for bugs before you make an
actual release out of it for the larger public.

As a knowledgeable CVS using developer i should know that your most
current module code is at HEAD and, if i need it, im perfectly able to
update to that if i am brave or posses the requisite skills to know that
it is safe.

Managing the code the way described above has a number of advantages:

* HEAD is the most current code as expected and can be expected to be
broken without concern for any period of time
* All branches are roughly equal in that they are "decently stable" and
represent a DX compatible version of the module.
* Faux beta testing before module releases by backporting.
* Your workload is eased and possibly distributed to others from the
constant patch dance.

As a daily user of the CVS system I would prefer that branches contain
"stale code" to "knowingly unstable" HEAD quality code. I can very
easily backport the HEAD myself if i am inpatient and want those changes
for my branch (regardless of if it is current or past branch) and even
submit a patch for the job should i like to see it upstreamed quicker.

Now im certainly not asking anyone to bend to the way that I do
something but I would like to see a certain level of organization in the
CVS tree so that collaboration and code management does not become a
larger shared problem for everyone.

Anyone else agree?

-- 
Michael Favia                   michael at favias.org
tel. 512.585.5650        http://michael.favias.org