Docs Example; The aftermath of an APACHE_2_0 branch

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

For those interested (expecially committers), this is how I picture
cvs usage changing;  I'm going to take the 'simple example' where
we presume most docs efforts are committed back to the 2.0 branch
from our development tree.  And we will presume most folks work on
docs within the 2.1-dev tree (that is, CVS HEAD).

Let's presume that we branched the APACHE_2_0_BRANCH tag
at APACHE_2_0_44, and then tag head with DOCS_MERGED_2_0_44
to include the auth changes as a 'starting point' (we might or might
not immediately also tag and create an alpha tarball of APACHE_2_1_0, 
that doesn't matter for this discussion.)

I'd suggest one maintainer on docs handle this once per 2.0 release
since it's much simpler on that side.  That individual, right before we
roll 2.0.45 would;

  cvs co -d httpd-2.1 httpd-2.0
  cvs tag DOCS_MERGED_2_0_45 httpd-2.1

so now we have a new point to start the merge next time... then we
continue to perform the actual merge...

  cvs co -r APACHE_2_0_BRANCH httpd-2.0

so they have the current head of Apache 2.0 development.

  cd httpd-2.0/docs/manual
  cvs up -j DOCS_MERGED_2_0_44 -j DOCS_MERGED_2_0_45

This is a REALLY shorthand for saying...

  cd httpd-2.0/docs/manual
  cvs diff -N -r DOCS_MERGED_2_0_44 -r DOCS_MERGED_2_0_45 >foo
  patch -p0 -N <foo
  cvs add {newly added files}
  cvs rm {newly removed files}

which might be easier for some.  Now we have picked up all the docs 
changes between those two merges, some are not appropriate.  But in
the docs case, for a while at least, most will be appropriate.

The next step is to massage any conflicts, new modules and directives
that don't exist in 2.1.  We don't expect any MASSIVE overhaul in the
2.x family (the next time we do a radical restructuring, it will probably
be time for 3.0.)  Some new directives will need to be documented for
2.1 only, perhaps, and some old directives might be deprecated.  But
(it seems to me) that most of the docs group work has been completely
restructuring the entire documentation, and most of those changes are
probably desireable for 2.0.  Certainly, when we add examples and other
goodness, we want that into the 2.0 doc family.

It's up to the docs group to decide if (and for how long) a single maintainer
can and is willing to deal with this.  Otherwise, it's simply a matter of
each individual committer applying their patches to both trees, except
for documentation of new or removed features in the 2.2 release.

Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org