[Top][All Lists]

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

Re: Merging on Vendor releases

From: Nick Patavalis
Subject: Re: Merging on Vendor releases
Date: Mon, 2 Dec 2002 19:43:43 +0200
User-agent: Mutt/1.4i

On Mon, Dec 02, 2002 at 07:03:36PM +0100, Fabio Fracassi wrote:
> What I like to do is porting one local change at a time e.g. I 
> have the following tags
> VendorRelease
> basicChanges
> extension1
> extension2
> product
> I'd  like to take the new Vendor version and first apply the basicChanges, 
> then test and debug the whole mess, and then go on with extension1 and so on.

This is indeed a complicated operation. I have not attempted this
myself, and I believe you should consider doing the merge in a signle
step, but then again it depends on the complexity of the local
changes. If you still want to do a piecemeal merge you should go like
this, but *do* take my words with a grain of salt!

First create a branch rooted at "basicChanges", like this:

  cvs rtag -b -r basicChanges b_basicChanges

Then checkout from this branch:

  cvs co -r b_basicChanges

Then merge the vendor changes in it:

  cvs update -j VendorRelease -j VendorRelease_new

Fix the conflicts, test and make sure everything works fine. Then
commit in the branch:

  cvs commit

Then merge in the branch the "extension1" changes:

  cvs update -j basicChanges -j extension1

Again resolve the conflicts, and commit.

  cvs commit

Finaly merge the "extension2" changes:

  cvs update -j extension1 -j enxtension2

Resolve the conflics and commit for the final time.

default, n.: The vain attempt to avoid errors by inactivity.
  -- Stan Kelly-Bootle

reply via email to

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