info-cvs
[Top][All Lists]
Advanced

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

Re: strange merge issue between two local branches


From: Tim Mooney
Subject: Re: strange merge issue between two local branches
Date: Wed, 23 Apr 2003 16:49:41 -0500 (CDT)

In regard to: Re: strange merge issue between two local branches, Greg A....:

>[ On Tuesday, April 22, 2003 at 13:58:38 (-0500), Tim Mooney wrote: ]
>> Subject: strange merge issue between two local branches
>>
>>
>> I then created a couple of branches from there, and committed two
>> different versions of our local patches to those two different branches:
>
>You cannot reliably use normal CVS branches in a vendor-branched module
>(i.e. one created with "cvs import" and where "cvs import" is used to
>add new vendor releases).  The two simply do not mix (and conceptually
>cannot mix either since the vendor branch trick is completely at odds
>with normal CVS branches).
>
>Vendor branched modules can have two, and only two, branches:  The
>trunk, where local changes are made, and the vendor branch (1.1.1) where
>vendor revisions are imported.  Merges are done to the trunk.

The news isn't what we wanted to hear, but thanks for sharing.  We clearly
still have a lot to learn regarding CVS.

Ok, let's say that we use CVS the way it was intended and documented for
tracking third party sources.

- We import IMAP 2001a to the vendor branch, and then check it out and
make some changes that are committed to the trunk.

- We later import IMAP 2002 to the vendor branch, do a merge of the vendor
versions to account for structural changes, and then check it out and
make some changes that are incompatible with our previous changes on the
trunk.  We commit these new changes to the trunk.

- Some time down the road, we find out that the local mods living on the
trunk and based on the 2001a version are incomplete, and we need to fix
something and commit it to the trunk, but we already have newer local mods
to a newer version of the vendor sources living on the trunk.

At that point, how do we get our fixes for the earlier local mods
"inserted" in the right spot on the trunk?

>I would recommend to you that you start over, and instead of using "cvs
>import" you'll need to manually put the vendor releases on some branch
>(either the trunk or some manually created "normal" CVS branch
>designated to the vendor, the choice depends on a great many factors).

Can you elaborate on some of the factors (pointers to areas of the
Cederqvist I should study are fine)?  It seems to me like if we use
the trunk for this purpose, it's going to be too easy for inexperienced
CVS users (our entire group, myself included) to check that out by
accident and start making changes that end up on what we want to have as the
pure vendor sources.

>You will then have to manually commit every new vendor release to its
>branch and then merge every nre vendor release to every local branch
>that you want to "bring current" with the new vendor release.

This sounds like it could become a very error-prone procedure, but I
appreciate the suggestion.

I have to believe that other sites have run into similar issues (tracking
multiple versions of local mods against multiple versions of third party
sources) before.  Are we just approaching this problem from the totally
wrong angle, or am I right in thinking that this is something that people
want to be able to accomplish with some kind of change tracking system?

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




reply via email to

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