This was exactly what I was looking for, thanks Tom.
>>
>> The tip of the tree (checkout with no branch or tag) is always the
>> latest code; currently it is 6.6-to-be. For the last couple
>> of versions
>> we have made a practice of starting a branch for back-patch
>> corrections
>> to existing releases. For example:
>>
>> 6.3
>> |
>> |
>> 6.4
>> | \
>> | 6.4.1
>> 6.5 \
>> / | 6.4.2
>> 6.5.1 |
>> / current
>> 6.5.2?? |
>>
>>
>> If there is any further activity in the 6.5 branch, it'd be
>> to produce a
>> 6.5.2 bug-fix release. We don't generally do that except for really
>> critical bugs, since double-patching a bug in both the tip
>> and a branch
>> is a pain.
Double-patching is a pain, but I thought that that was the point of using
CVS to do your branching. AFAIK, CVS will merge the bug-fixes in, say, the
6.5.1 branch back into the main branch. Because you want to fix the bugs in
6.5 into 6.5.1, without having to double-patch, but new development must
only go into the main branch. So, when 6.5.1 is released, it is merged back
into the main branch to pass the fixes over, and also carries on to 6.5.2 in
a continuation of the existing branch.
Anyway, ideas for Marc.
Thanks again, this is great. Should go into the developers docs.
MikeA
