[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Again: multiple vendors
From: |
Pierre Asselin |
Subject: |
Re: Again: multiple vendors |
Date: |
Sun, 6 Mar 2005 21:54:09 +0000 (UTC) |
User-agent: |
tin/1.6.1-20030810 ("Mingulay") (UNIX) (NetBSD/2.0 (i386)) |
Baurzhan Ismagulov <address@hidden> wrote:
> On Fri, Mar 04, 2005 at 02:42:56AM +0000, Pierre Asselin wrote:
> > The multiple vendor branch was not funny, so I agree with Greg.
> > I had to manually reset many "admin -b" values, move files in and
> > out of the Attic (I think), etc. When I got to the point where
> > a plain trunk checkout gave me a current main-vendor release,
> > I could start working.
> Do I understand you correctly: it did work for you with import -b,
> right? Do you mean it would be easier to do with normal branches,
> applying upstream patches by hand and committing?
That's one way, if you are careful about added and deleted files.
> In particular, I don't
> see why you had to reset admin -b values and move files in / out of the
> Attic; do you remember concrete scenarios?
Because you get an inconsistent trunk. Example with two vendor
branches:
first
both imported to 1.1.1
both
second imported to 1.1.3
If you check out a trunk sandbox, you get all three files, which
doesn't correspond to anybody's release. The "both" that you
get is the 1.1.1.1 revision, not the 1.1.3.1, because its "admin
-b" branch is 1.1.1 from the initial import and was not reset by
the second import.
Hm, maybe it's not as bad as I think. I just tried this example
and cvs warned me of a conflict. I don't remember that from before.
Maybe the conflict detectors have improved ? This is cvs 1.11.17 .
First import
--------------------------------------------------
date > first
date > both
cvs import -m'main vendor' test VENDOR main-1_0
N test/first
N test/both
No conflicts created by this import
--------------------------------------------------
Second import
--------------------------------------------------
rm first
date >> both
date > second
cvs import -m'variant' -b 1.1.3 test VARIANT var-1_0
N test/second
C test/both
1 conflicts created by this import.
Use the following command to help the merge:
cvs checkout -j<prev_rel_tag> -jvar-1_0 test
--------------------------------------------------
I guess the broken trunk is just the normal result of an unmerged
import. To standardize on the main vendor branch,
cvs checkout -d test_main -j var-1_0 -j main-1_0 test
and I get a test_main/ sandbox consistent with the first import.
If I commit that, file "second" gets a dead trunk revision 1.2 and
its "admin -b" branch is reset to empty. So maybe I could have
saved myself all that surgery by doing proper post-import merges.
Note that I gave my "checkout -j" options in the opposite order
from the cvs suggestion because I want the trunk to look like the
main vendor branch, not the 1.1.3 variant.
Okay, so select a favorite vendor (you can't treat them symmetrically)
and import all his tarballs normally. Do all your post-import
merges religiously in order to take care of deleted files.
THEN, start importing alternate vendor tarballs to secondary
branches. Always do the post-import merges to trunk, but
merge from -j<just-imported> to -j<final-main-import>.
After that, a trunk checkout should give you the equivalent of a
fresh tarball from your privileged vendor. All the other tarballs
are in CVS with unique import tags (keep good notes as you import)
so you can start merging tarball deltas.
BTW, you can do this in a private cvs repository on your own
computer, accessed in local mode. If you stumble, wipe out the
whole thing and start over. If you succeed, scp your repository
tree to the real cvs server.
--
pa at panix dot com
- RE: Long version numbers | Tedious to keep track, (continued)
- RE: Long version numbers | Tedious to keep track, Jim.Hyslop, 2005/03/02
- Re: Long version numbers | Tedious to keep track, Todd Denniston, 2005/03/02
- Again: multiple vendors (was: Re: Long version numbers | Tedious to keep track), Baurzhan Ismagulov, 2005/03/02
- Re: Again: multiple vendors, Greg A. Woods, 2005/03/03
- Re: Again: multiple vendors, Baurzhan Ismagulov, 2005/03/03
- Re: Again: multiple vendors, Greg A. Woods, 2005/03/03
- Re: Again: multiple vendors, Baurzhan Ismagulov, 2005/03/06
- Re: Again: multiple vendors, Kaz Kylheku, 2005/03/07
- Message not available
- Re: Again: multiple vendors, Pierre Asselin, 2005/03/03
- Re: Again: multiple vendors, Baurzhan Ismagulov, 2005/03/06
- Message not available
- Re: Again: multiple vendors,
Pierre Asselin <=
- Re: Again: multiple vendors, Baurzhan Ismagulov, 2005/03/20
- Re: Again: multiple vendors, Larry Jones, 2005/03/04
- Re: Again: multiple vendors, Baurzhan Ismagulov, 2005/03/06
Message not available
Re: Long version numbers | Tedious to keep track, Xapp, 2005/03/02