Re: Again: multiple vendors

[Pierre Asselin]

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