From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-23 08:16:24
At 11:36 AM 1/22/2002, David Abrahams wrote:
>
>----- Original Message -----
>From: "Beman Dawes" <bdawes_at_[hidden]>
>
>> If we do that, is there a way to do a commit that says "commit this
>change
>> to both the main trunk and the release candidate branch?
>
>No, but I can make you an easy Python script to do it.
>
>> If not, who is responsible for merging fixes back into the main trunk?
>
>Individual developers. They will be motivated to do it; remember they're
>going to get mail if they leave bugs in the code. Anyway, these changes
>will
>be few. If they need to go back and find the fix, they can just do a
merge
>with the last release.
>
>After the release, someone (anyone) can do:
>
> cvs update -AdP
> cvs -n update -dP -jVersion_<last-release>
>
>Note the files that would be merged, and notify the group or appropriate
>authors. Again, this should be relatively few files.
>
>> Or merging changes from the main trunk into the release branch?
>
>That shouldn't happen, really. When you get notice of a bug in the
release
>candidate, you go back to that branch and fix the bug. Then if you want
it
>in the main trunk immediately you can:
> cvs update -j<release-branch-tag> filenames...
>
>> How do other
>> people typically ensure that the merge actually gets done? Without
>> becoming a time waster or administrative nightmare?
>
>I don't think there's anything to fear with this model.
Well, let's give it a try for a release or two.
I'll update the procedure doc accordingly.
What would be a help is if you would figure out the command line cvs
procedure for the following scenario:
Developer's working copy contains the (possibly slightly out-of-date with
respect to the repository) main trunk with some new work-in-progress
changes made to unrelated files. Developer wants to fix a bug in a release
candidate file. What is the procedure so that at completion:
* Both the repository main trunk and release candidate branch have the bug
fix applied.
* The developer's working copy is set back to the main trunk again, and his
or her work-in-progress is still present as are the bug fixes.
I'll work out and test the same procedure for a WinCVS developer.
--Beman