[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Off list comment (was: Re: Maintaining branches...)
From: |
Mike Castle |
Subject: |
Off list comment (was: Re: Maintaining branches...) |
Date: |
Mon, 18 Jun 2001 14:12:23 -0700 |
User-agent: |
Mutt/1.3.18i |
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
- Re: Maintaining branches..., (continued)
- Re: Maintaining branches..., Greg A. Woods, 2001/06/14
- Re: Maintaining branches..., Eric Siegerman, 2001/06/14
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Re: Maintaining branches..., Derek R. Price, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Re: Maintaining branches..., Derek R. Price, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Off list comment (was: Re: Maintaining branches...),
Mike Castle <=
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Eric Siegerman, 2001/06/14
- Re: Maintaining branches..., Paul Sander, 2001/06/15
- Re: Maintaining branches..., Mike Castle, 2001/06/15
- Re: Maintaining branches..., Paul Sander, 2001/06/16
- Re: Maintaining branches..., Mike Castle, 2001/06/16
- Re: Maintaining branches..., Paul Sander, 2001/06/16
- Re: Maintaining branches..., Mark, 2001/06/15
- Re: Maintaining branches..., Paul Sander, 2001/06/16
- Re: Maintaining branches..., Mark, 2001/06/18