bug-cvs
[Top][All Lists]
Advanced

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

Re: import inconsistency


From: Pierre Asselin
Subject: Re: import inconsistency
Date: Wed, 18 Jun 2003 22:09:45 -0400
User-agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.19-7.0.1 (i586))

Paul Edwards <kerravon@nosppaam.w3.to> wrote:
> "Pierre Asselin" <pa@invalid.invalid> wrote in message 
> 9q1mcb.fe2.ln@brick.verano.sba.ca.us">news:9q1mcb.fe2.ln@brick.verano.sba.ca.us...

>> You overestimate what import can do.  [ . . . ]

> That's not true.  That is precisely why there is a "-b" in
> the cvs import, to support multiple vendor branches.
> [ . . . ]
> It seems well-entrenched to me.  We've had "-b" in import since
> way back in something like CVS 1.3.

Yeah, that doc suckered me in too.  Now I know better.


> [ . . . ]
>> or you rejuvenate your branch by sprouting a new one off
>> the up-to-date stuff, merging your old branch to the bud, and killing
>> the old branch.

> Every week?  A logistical nightmare, which the programmers
> will definitely stuff up (and blame both me and CVS, and get
> the backing of their bosses who don't understand either).

But that's a job for *you*, not the programmers!  You maintain a trunk
using import, with release tags US1, US2, US3 etc.  Each of those has
a branch, AU1, AU2, AU3 ...  containing the local work, of which only
the last is active.  This last branch has a second name, such as CURRENT.

    cvs admin -NCURRENT:AU3

Every programmer has a sandbox checked out with sticky tag CURRENT.
On Sunday night, you import and stabilize US4 on the trunk.

    cvs import blahblah VENDOR US4-import
    cvs checkout -j US3-import -j US4-import
    ...
    cvs commit; cvs tag US4

You replicate the local work to a new branch,

    cvs tag -r US4 -b AU4
    cvs update -r AU4
    cvs update -j AU3
    (fix conflicts, swear, etc.)
    cvs commit

and you move the branch alias,

    cvs admin -NCURRENT:AU4

On Monday morning, the first developer to try a commit (with sticky tag
CURRENT) is told to update because the tag has moved!  So (s)he updates,
still with the sticky tag.  Presto, CVS switches the sandbox to AU4,
which has the latest US code, without losing the uncommitted changes.

The developer's updates ought to be relatively painless.  Your own merge
of AU3 with US4 will be more annoying, because you'll find that US4 has
accepted many changes from AU3 and you'll get bogus conflicts with the
same text on both sides.  But that's your job :-)

So that's how I would do it, if I had a single import stream from
the remote site.  You seem to be managing several incoming streams?
I don't know how I would handle that.  Your multiple vendor branches
*may* work, since you don't use a trunk and your vendor branches are just
holding areas.  I guess your're doing fine, I just don't understand your
process --or your constraints.


> Anyway, as I keep saying, CVS is "pretty bloody good"!  :-)

No argument here.



reply via email to

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