Обсуждение: RE: [HACKERS] CVS

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

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
>>> 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.

The trouble is that the tip usually diverges fast enough that mechanical
application of the same diffs to tip and stable branch doesn't work
very well :-(.

Also, our usual practice is to prove out a bugfix in the tip and then
consider whether to apply it to stable branches.  I'm not sure whether
CVS supports that as easily as merging a branch to the tip, but I'd
be *really* wary of mechanical diff transfer to stable branches...
if the diff extracts too little or too much of the changes in the
tip file, you might not find out till too late.
        regards, tom lane