Re: import inconsistency

[Paul Edwards]

"Pierre Asselin" <pa@invalid.invalid> wrote in message 
916rcb.s36.ln@brick.verano.sba.ca.us">news:916rcb.s36.ln@brick.verano.sba.ca.us...
> 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.

Anything specific that doesn't work?

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

That is a very interesting suggestion!  I was thinking that this
was a better way to do it.

> On Sunday night, you import and stabilize US4 on the trunk.

But this is where the problems start to arise.  When I got to
work today, we got two shipments (ie release 3.1 and release
3.2) overnight from the US.  A programmer was hassling me
all day what was in it and why wasn't installed, I was holding
him up.

>     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 this is the second problem.  The programmers fix the conflicts
themselves, it's not my job.  USA is the master, and they must make
their changes on top of the US.  I'm not responsible for either fixing
the US's code to fit their change, or vice versa.

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

And this is the third problem.  I can't stop the programmers from
continuing using the system while the conflicts are being resolved.
By the time I finally have all the conflicts resolved, they've
normally committed more stuff, so I need to do a cvs update myself
before doing the commit.  Sometimes that gives me even another
conflict!!!

> 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 :-)

Actually, initially I thought I would get lots of bogus conflicts,
but it turns out that CVS is smart enough to see that if we both
made exactly the same change, then that is acceptable and
doesn't need to show up as a conflict!

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

Hopefully I've explained that.

My multiple vendor branches definitely do work.  The only
problems I have encountered so far I've already submitted
patches for, or Derek has fixed.

The files in the Attic (or more accurately, everyone else's
experimental imports NOT in the Attic) is not an integrity
problem, it's just an inconsistency, it doesn't stop my work.
The only integrity problem I didn't see Derek commit yet
is the "has been added" not causing a conflict one.

I am wondering whether I should combine your branch alias
technique with what I am already doing.  Because one problem
I have is that code is originally developed using release-3_1
as a base, and now we need to switch to release-3_2, but
even then, it's only me that switched for delivery purposes,
they kept using release-3_1.  But finally the release-3_2
environment (database etc) was ready and they had to
abandon their avs-3_1 branch and switch to avs-3_2.  I had
to ask them to delete their old working directory.  If instead
I had a branch alias of AVS, I could have switched that
myself, and they wouldn't have had any choice.  :-)  That is
sounding very good.  I'll probably make the alias just "avs"
so they can go cvs checkout -r avs avs.  Both aliases.
Excellent!  Thanks!

BFN.  Paul.