[Top][All Lists]

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

Re: Reverting a "cvs import"

From: Greg A. Woods
Subject: Re: Reverting a "cvs import"
Date: Fri, 8 Mar 2002 21:49:36 -0500 (EST)

[ On Friday, March 8, 2002 at 16:00:16 (-0800), Stephen Rasku wrote: ]
> Subject: Reverting a "cvs import" 
> We have a product that is made up of a lot of third party open source 
> modules (Apache, Perl, IMAP, etc.).  We want to upgrade to the latest 
> version of these modules.  
> Typically we would do this by importing the latest version of these 
> modules into our repository.  However, I don't see this as a seamless 
> process.  I expect to see some modules that are not as stable as 
> others and will have to be reverted to an earlier version (but a later 
> version than what was originally in CVS).  Is there a way to do this?  

Well of course, though it may not be as easy as you want it to be, and
it will have future implications that you may not wish to suffer.

So go the ways of the mostly magic and very limited CVS vendor branch

> Additionally, we have various customizations to the existing stuff on 
> the trunk.  When I have done an import in the past, the imported stuff 
> shows up on the trunk after the import.

Yes, this is yet another of the limitations of CVS' vendor branch
"feature" -- you need to freeze local development before doing any
merges, and make sure everything's committed and tagged.  It's not
terribly useful for larger (and multi-person) projects.....

>  This is not what I want since 
> this is where we are getting the current product from.

Then you should probably not try to use the vendor branch support at all
(i.e. do not use "cvs import"), but rather create a "normal" branch and
pretend to be the vendor and commit their releases to it, tag it
yourself, etc.  You'll have to be very careful to do all the necessary
adds and removes too.

You can then create a new branch forked from every release you commit to
the vendor branch onto which you can apply any local changes, and finally
you can merge the delta between this new branch and the last one of its
kind to the trunk.  From there you may wish to fork off a local release
branch too.

>  Is there a way 
> to import to a branch so the person doing the importing can import and 
> check in modifications to this branch without affecting the trunk 
> until the new stuff is ready to be merged?  I am not talking about 
> vendor branches here (I don't think.)

You really do not want to mix local changes with vendor changes (i.e. do
not ever manually commit to a magic vendor branch).

I think you really do need at least three branches to do the sort of
thing you say you are trying to do now with a magic vendor branch.

                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

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