Re: Again: multiple vendors

[Baurzhan Ismagulov]

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 <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.