Re: Patching and Releasing

[Eric Siegerman]

On Fri, Jul 27, 2001 at 03:08:08PM -0700, Kent Henneuse wrote:
> I want to be able to determine the changes that have happend on
> a branch between two different dates.  This will then be used
> to make up a patch that can be added to fix defects.
> 
> Ideas I have had are:
>   Tag the branch with each patch that goes out.

Absolutely!  I don't trust -D -- not because of any bugs; I don't
know of any -- but because it's imprecise.  Do you remember
*exactly*, to the second, when you did the "cvs update" that went
into that distribution you made three weeks ago?  Then how do you
know, when you do an "update -D" or "diff -D", that you're
getting *exactly* the same set of revisions you got then.

>   Create a branch for each defect fix

Probably overkill.  The advantage of this is that it would:
  - let people do intermediate commits on the way to fixing the
    defect
  - let a team work on that particular defect
while still isolating that defect-fix code from whatever else is
going on.  The downside is:
  - lots more branches, with a lot of bookkeeping effort to keep
    track of which ones you've merged into the development
    mainline
  - doing all those merges, one per defect

Consider a hybrid approach:
  - create a single branch, rooted at the latest release, for all
    post-release bug fixes 
  - commit fixes to that branch, tagging each one
  - if a particular bug looks as though it will take a while to
    fix, or people need to collaborate on fixing it, only then
    create a branch (rooted at the tip of the bug-fix branch) to
    support the work.  Then, when the work has been done, merge
    the little per-bug branch back into the main bug-fix branch
    (and then, perhaps a long while later, from there back into
    the development mainline).


>   Write out a file with a unique name statting the defect and the files 
>     changed

Might like a good idea.  It wouldn't have to be a different file
per defect; it could be a single (CVS-controlled) file, something
like the ChangeLog files in GNU packages.  Rather than writing a
new file, the program that generated this data could just prepend
it to the existing change-log file; the CVS commit would take it
from there.  Downside: if two people worked on different defects
in parallel, the second one to commit would get a merge conflict
on the change-log file.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)