Hello, I've tried both and found that normal (as opposed to vendor) branches were easier to understand and not that difficult to implement ($Log$ turned out to be solvable just like other keywords), so that is what I did.
Thanks much for all replies! With kind regards, Baurzhan. On Sun, Mar 06, 2005 at 09:54:09PM +0000, Pierre Asselin wrote: > Baurzhan Ismagulov <[EMAIL PROTECTED]> 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. _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
