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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
