CVS Branching and Merging

Chad Walstrom wrote:
> As far as a timeline, I would like to start preparing a 4.1
> pre-release ASAP.  There have been some CVS updates since the original
> 4.0 release, and it's a good time mark the codebase before branching
> off for the big changes in 4.2 and 5.0.

Let me rephrase that.  We should probably branch releases and leave the
trunk as the development branch.  In which case, we tag the trunk for
the 4.1 release as release_4_1, then create the maintenance branch as
release_4_1_branch.  Patch releases to the 4.1 series would then be
tagged from that branch: release_4_1_1, etc.

We don't need to get carried away with judicious branching, but if you
feel comfortable using a branch to work on feature enhancements, please
feel free to do so.  Let's leave the trunk for merging.  For example,
Mel is planning big changes, so perhaps he branches off the trunk as

    {featurename|author}_{revision-branching-from}_dev
    
And, when you're ready to merge to the trunk, merge from the trunk to
get the updates and tag (with '_merge') after conflicts are resolved.
Then whoever is in charge of merging to the trunk will pull from that
tag.  Once merged, we can tag the target trunk/branch with a "_merged"
tag.

Ideas?  Overkill?

I know CVS operations to savannah are a bit slow, but it's workable.
What do you all think of judicious tagging?  i.e.  Tagging the
merge-points of bug fixes or feature additions?

-- 
Chad Walstrom <[email protected]>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

_______________________________________________
Help-gnats mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gnats

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAz2AXDMcLGCBsWv0RArIIAJ918ozDbEWvzERnvHGd63qizHpMnQCfY5D+
KyFGK3C1D2NfxCTQlYmbYvs=
=TkmF
-----END PGP SIGNATURE-----