Off list comment (was: Re: Maintaining branches...)

[Mike Castle]

Sorry to bring this up here, however, someone recently sent me an off list
question regarding this particular message I had posted.

Unfortunately, I fat fingered it and deleted the message.  :-<

If the person is still interested, feel free to contact me again.

Apologies,
mrc

On Thu, Jun 14, 2001 at 02:44:52PM -0700, Mike Castle wrote:
> 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

-- 
     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