info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Handling multiple merges (was RE: CVS bashing?)


From: Keith Hearn
Subject: Handling multiple merges (was RE: CVS bashing?)
Date: Fri, 13 Apr 2001 15:20:00 -0700

Mike,

Below, one of the commands you say to run is "cvs tags". I don't think
that's right. At least, it's not documented in Cederqvist, and it's not
implemented in my version 1.10.7. As you said, it's been a while since you
used cvs, so I suspect you've got the command name mixed up. Any idea what
the actual command might be?

Thanks,

   Keith Hearn


> -----Original Message-----
> From: Mike Castle [mailto:address@hidden
> Sent: Friday, April 13, 2001 10:42 AM
> To: address@hidden
> Subject: Re: CVS bashing?
> 
> 
> On Thu, Apr 12, 2001 at 08:34:33AM -1000, Joseph Dane wrote:
> > >>>>> "Mike" == Mike Castle <address@hidden> writes:
> >  Mike> As I said in an earlier post, this can be scripted around.
> > 
> > can you give me an idea as to what such a script might look like?
> > wouldn't there have to be some sort of 'database' which 
> kept track of
> > when/where the prior merges happened?
> 
> The database would be cvs tags.
> 
> Rather than actual code, this is what I used to do manually.  (Mostly
> because I was doing all of the work under NT and wasn't using 
> Cygwin and
> wasn't up to speed on the batch language improvements, so I 
> never scripted
> it before).
> 
> Lets say we have one branch, ver_2_0, and the main line.
> 
> I made a series of bug fixes to ver_2_0 and now I want to 
> merge those onto
> the main line.
> 
> (Be forwarned, I've actually not used cvs in a while, now working in a
> perforce shop, so if I screw up syntax somewhere, please 
> forgive me.  But
> also please post corrections!  Also, may not be the most 
> effecient way.)
> 
> :: First, to the branch.  Just in case any other sticky tags, 
> get rid of them
> cvs up -A     
> cvs up -r ver_2_0
> :: Look for any previous merges (maybe no cygwin, but Borland 
> has grep ;-):
> cvs tags | grep merge_ver_2_0_to_main
> :: None, so start at 1
> cvs tag merge_ver_2_0_to_main_1
> :: Move to main branch
> cvs up -A
> :: do the merge
> cvs up -j bp_merge_ver_2_0 -j merge_ver_2_0_to_main_1
> :: do any conflict resolution and so forth
> cvs commit -m "merged ver_2_0 from branch point to 
> merge_ver_2_0_to_main_1"
> 
> So now we do some more fixups on the ver_2_0 branch and we go 
> through the
> process again:
> 
> cvs up -A
> cvs up -r ver_2_0
> cvs tags | grep merge_ver_2_0_to_main
> :: output is:
> merge_ver_2_0_to_main_1
> :: so now we know we're at 2
> cvs tag merge_ver_2_0_to_main_2
> cvs up -A
> cvs up -j merge_ver_2_0_to_main_1 -j merge_ver_2_0_to_main_2
> cvs commit -m "merged ver_2_0 from merge_ver_2_0_to_main_1 to 
> merge_ver_2_0_main_2"
> 
> 
> Some things that could simplify this:
> 
> If no output from the grep, then just tag the branch point with
> merge_ver_2_0_to_main_0 and then you can clean up the process 
> a bit and
> everythign with be in the form of _main_x to _main_{x+1}.
> 
> If anyone makes changes to the branch that should not be 
> migrated over, one
> could manually move the last checkpoint branch up past that 
> change so it
> doesn't move over next time.
> 
> mrc
> -- 
>        Mike Castle       Life is like a clock:  You can work 
> constantly
>   address@hidden  and be right all the time, or not work at all
> www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
>     We are all of us living in the shadow of Manhattan.  -- Watchmen
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]