[Top][All Lists]

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

Re: Again: multiple vendors

From: Baurzhan Ismagulov
Subject: Re: Again: multiple vendors
Date: Mon, 21 Mar 2005 00:04:01 +0100
User-agent: Mutt/1.5.6+20040907i


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

Thanks much for all replies!

With kind regards,

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 revision, not the, 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.

reply via email to

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