Re: Maintaining branches...

[Mike Castle]

On Thu, Jun 14, 2001 at 05:03:58PM -0400, Derek R. Price wrote:
> Mike Castle wrote:
> > But consider the following sequence:
> >
> > branch at 1.1.  Branch has 1.1.0.1 and 1.1.0.2.
> 
> I'm going to pretend these are valid branch version numbers for the sake of
> argument.

Thanks.  Been a while since I've actually branched with CVS (stuck using
perforce at work now).  And since I never really pay attention to them, I
always forget the numbering sequence it uses.

> > Changes 1.1.0.4 and 1.1.0.5 are made.  Now we want to migrate all of those
> > changes onto the main branch.
> >
> > So now we have to be able to tell cvs to:
> >
> > diff -r1.1 -r1.1.0.2, apply patch
> 
> > diff -r1.1.0.3 -r1.1.0.5, apply patch
> 
> I thought the idea here was that you could say "merge branch 1.1.0" and CVS 
> would
> say, "you already merged change A on DATE - (s)kip this portion or (r)emerge?"

Sorry.  I mean the -r1.1 -r1.1.0.2, apply patch, -r1.1.0.3, -r1.1.0.5,
apply patch was a matter of implementation, not presentation.

If the user chose skip, then I'd imagine it'd work like that.

I assume the remerge stuff would come from when cvs determining what it
needs to apply, rather than actually at application time.  Patch, for
instance, determines it at application time.

What about merging back and forth.

User makes change 1.1->1.2, and merges it onto branch, then it gets merged
back.

Users would normally expect cvs to track that information and act
accordingly (ie, not present any conflicts based upon that particular bit).

But, since you could have +X amount of changes between the up -j and the
commit, you really can't do that.  There will be conflicts.

mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc