Re: How to avoid propogation of changes

[Eric Siegerman]

On Thu, Mar 15, 2001 at 03:06:03PM -0600, address@hidden wrote:
> On Thu, Mar 15, 2001 at 01:22:40PM -0600, David H. Thornley wrote:
> > address@hidden wrote:
> > > Here is the problem: What if we make a change that we don't want
> > > propogated downstream. [ie. merged from a one branch to the trunk]
> > 
> > [...] we maintain_MERGED tags on our branches, so
> > BRANCH_3 would have an associated BRANCH_3_MERGED tag.  We have
> > a Perl script that will merge from a branch to, say, head.
> > It merges everything from BRANCH_3_MERGED to BRANCH_3, and then
> > moves BRANCH_3_MERGED.  
> 
> > This means that the way to avoid
> > propagating a change is to move BRANCH_3_MERGED past it, and
> > this is indeed what we do (I've got a Perl script for that, too,
> > for consistency, and it's pretty short.)
> 
> This would require us to merge all of our files individually, whereas 
> we merge the entire branch in a single command,

I'll refer to such changes (ie. that aren't supposed to be propagated)
as "temporary changes".

Procedure 1: This is easiest, *if* you can get away with it.  If
you're about to check in a change that you know is a temporary
one, and if the people working on the mainline are willing to let
you do a merge, you can:
  - Merge the branch, and update its _MERGED tag
  - Check in the temporary change
  - Move the _MERGED tag past the temporary change


Procedure 2a: If you know the change is temporary, but you can't
do a merge at the moment, then tag the change, to make Procedure
2b easier when the time comes:
  - Make sure your sandbox on the branch is up to date
  - Tag the branch with a release tag.  I'll call the tag
    PRE_CHANGE, but of course your tag name should be a lot more
    explicit.
  - Commit the temporary change.
  - Tag the branch again (I'll call the tag POST_CHANGE).


Procedure 2b: This happens when you're ready to do the merge.  At
this point, your sandbox on the branch contains the temporary
change, as well as other changes that *should* be merged.  Do
this:
  - Make sure your sandbox on the branch is up to date.
  - Revert the temporary change.  Assuming you tagged the change
    as in Procedure 2, this looks like:
        cvs update -jPOST_CHANGE -jPRE_CHANGE
    Note the ordering of the -j options.  This says to *undo* the
    change.
  - Resolve conflicts; test; commit on the branch.  At this
    point, the branch contains the permanent changes, but not the
    temporary one.
  - Merge the branch, and update its _MERGED tag.
  - If you still want the temporary change *on the branch*, do
    this (which is essentially Procedure 1):
      - Reapply the temporary change:
          cvs update -jPRE_CHANGE -jPOST_CHANGE
        (Yup, the -j's are the other way around this time)
      - Commit it
      - Move the _MERGED tag past it


Procedure 3: If it's too late, and the temporary change is
already committed, but not tagged.  This looks like 2b, except
that two steps, "revert the temporary change" and "reapply the
temporary change", will have to be done file by file:
        cvs update -j1.5 -j1.4 foo.c
        cvs update -j1.17 -j1.16 bar.c
and
        cvs update -j1.4 -j1.5 foo.c
        cvs update -j1.16 -j1.17 bar.c
respectively.  More work than if it was tagged, but less than
doing the whole merge file by 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)