info-cvs
[Top][All Lists]
Advanced

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

Re: Merging from vendor-branch to branch


From: Greg A. Woods
Subject: Re: Merging from vendor-branch to branch
Date: Tue, 22 Oct 2002 18:16:31 -0400 (EDT)

[ On Wednesday, October 23, 2002 at 00:39:53 (+0300), Nick Patavalis wrote: ]
> Subject: Merging from vendor-branch to branch
>
> We have a cvs tree, on which we work for quite some time now since the
> sources were first imported. As a result a considerable amount of
> changes have been collected. Now the "vendor" has shiped a new version
> and we would like to merge the changes back to our tree. Due to the
> complexity of the task the mege will take several days. If we follow
> the normal merging procedure the main-trunk (used by all the
> developers not normally involved in the merge operation) will remain
> unstable for all that period.

yes, that's correct.  It's the price you must pay for having the clean
and simple capabilities of 'cvs import'

> So I'm wondering if it would be possible to perform the whole merging
> proccess on a branch and only when we 're finished (and reasonably
> sure that the resulting source-tree is stable) merge from this branch
> to the main trunk? How can this be done, if at all possible? What are
> the sugested practices for similar cases (not wanting to destabilizing
> you trunk durring a painfull merging period)?

It's not really safe to use "normal" branches in a vendor-branched
module, at least not one in which you plan to do more "cvs import"s to
the vendor branch.

The problem is that unless _all_ of the files, i.e. every single one of
them, have local modifications (i.e. revisions of 1.2 or greater on the
trunk), then the base of any branch you create will, by default, be
spread across the trunk and the vendor branch.  This causes all kinds of
subtle and not-so-subtle problems with various CVS operations.

I've not tried to very carefully create a branch only on the trunk and
to merge "up" the head of the vendor branch to this branch, and then to
do an import and to do a merge on a branch.  This might work, but it
will may cause you to get into a situation where in the future you'll
have to always merge every file to the trunk regardless of whether there
are really local changes in it or not.  You might want to create a small
test module and try this a few times to test -- you'll want to have
locally modified files and locally unmodified files and you'll want to
add new local changes to previously unchanged files at each step.

You might find that you end up having to work on that new branch and
that you have to create a new branch for every vendor release and to
always merge your local changes up to that new branch every time instead
of the normal vendor-branch scheme of only merging vendor changes to
locally modified files.  If that's the case then you would be better off
to forget "cvs import" and simply always do full merges on a "normal"
branch created for the vendor (where you manually check in and manually
tag new vendor releases instead of importing them).

By manually managing vendor releases on their own "normal" CVS branch
you have full control over all merges and you can do them in isolation
in a (set of) working directory(ies) without having to disturb anyone.
This scheme is more work, but it also allows you to easily and safely
create release branches too.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <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]