Re: import inconsistency

[Paul Edwards]

"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...
> > I had another thought about this.  Let's take a project we are
> > more familiar with - CVS itself.
>
> > There's actually two versions of CVS, potentially even more,
> > but let's say 2.  cvs1-11-x and cvs1-12-x when all is said and done.
>
> > Assuming you wish to operate on your own machine, not
> > permanently connected to the internet, you would have imported
> > these as a foreign source.
>
> You overestimate what import can do.  It only handles a single stream
> of releases from the outside, plus local changes.  Two release streams,
> you're hosed.

That's not true.  That is precisely why there is a "-b" in
the cvs import, to support multiple vendor branches.

> > So you have two vendor branches, with the above names.
> > No head yet.
>
> The support for multiple vendor branches is very weak.

It seems well-entrenched to me.  We've had "-b" in import since
way back in something like CVS 1.3.

> There's enough
> to export any previous import by tag name, or run diffs against any two,
> but if you want to manage local changes you have to perform a whole lot
> of clerical work manually before you can even get started.

I'm not quite sure what clerical work you have in mind, but I
assume you are talking about my job.  Yes, the whole thing is
tagged to buggery.  But the tags are all placed across the entire
source tree, I don't need to manage individual files.  That's
what it's all about.

> > And you've been diligently importing every drop of cvs1-11,
> > ie cvs1-11-1, cvs1-11-2 up to cvs1-11-6.
>
> Ok, you can track the 1-11 series with imports, but don't forget
> to merge each import to your trunk,

Sorry, the trunk is where I was initially managing the cvs1-10
stream (pretend they started distinguish release/development
earlier), before I realised that it was inconsistent.  In actual
fact, that's pretty much what I did on my system.  I have one
branch that is 1.1.1.  I shouldn't have done that, as now it is
inconsistent with all the other branch numbers which are
numbered after the release.  E.g. all the release 3.2 stuff has
been allocated branches of 1.1.325 (for the main import)
and 1.1.321, 1.1.323, 1.1.327 etc for projects.  It's quite
unfortunate again actually, I should have called it 1.1.3255
to give me two-digit numbers for the branches.  And as if
that wasn't bad enough, when we get to release 10 there will
be another sequence of range clashes.  :-(

> even if you haven't made any
> changes yet, or files won't die that should have.

They do die on my project branch.

> > It is only on
> > cvs1-11-6 that you decided you had a mini-project to fix a
> > problem here.  Some codswallop about diff/rdiff not working
> > properly.  The logical thing to do is whinge like
> > hell^H^H^H^H^H^H^H^H^H^H^H make a branch on
> > cvs1-11-6, with cvs rtag -b -r cvs1-11-6 difffix-1-11 ccvs.
>
> Anyone else would have put the change on the trunk.

Trunk had local modifications to cvs1-10.  What happens to
them now?

> > You may not even finish your project before cvs1-11-7 comes
> > out, so you end up merging cvs1-11-7 onto you branch so that
> > you don't need to stuff around with another branch for no
> > particular reason.
>
> And here is another road to perdition:  merging to a branch instead of
> from one.  Typically, you *don't* bring your branch up to date.

Just today I abandoned an avs-3_1 branch because we are now
making future changes on the 3_2 code stream, so I have set up
an avs-3_2 branch.  I've told all the developers on avs-3_1 to
delete their working directories and recheck out on avs-3_2.
That is traumatic enough already.  I personally visited all those
involved and looked into their eyes to see if they understood.
Forget doing that every week for every project!!!  Now all
they need to do is a "cvs update" every week.  The command
doesn't change, and it failsafes when the programmers, being
normal programmers, are completely absorbed in their own
change and ignore my email about needing to do a "cvs
update" until such time as it is time to commit.

Programmers have zero interest in source control, they are
focussed on their individual changes, and incidentally, so
are their bosses.

> You keep
> coding on the old base,

We need to find out about problems with other people's
code interacting with ours as early as possible.  It is more
productive to find and fix the conflicts now.

> or you merge your branch to the up-to-date stuff
> and kill it,

Can't kill it, ongoing development ever-present.

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

> It's quite difficult to re-sync two parallel code-lines in CVS.
> Possible, but difficult.  It requires rigorous tagging to keep track of
> what changes have already been propagated where.

Yes, this is my job.  Mr Rigorous.

> It's *much* easier
> to keep all the merges unidirectional, even if it means working out
> what branches are subordinate to what other branches or to the trunk.

All the merges are unidirectional - to the project branch, at
least from the programmer's point of view.  I can't think of
a more comfortable environment for them.

> The CVS releases are a case in point.  Bug fixes from 1-11 will be folded
> into 1-12, but new features in 1-12 won't go into 1-11.  (Never say never,
> back-ports can be made, but they're the exception.)

I wouldn't agree with this at all.  Many developers love to
be working on the latest greatest version of everything, and
damn that stupid "release" branch for the nancy-pancy
fairies.  Erm, excuse me, mind if I snaffle that excellent
bug fix you just did while madly hacking away?  I happen
to need that myself.

> > Since variety is the spice of life, you decide to fix the Attic
> > misnomers by creating an attic-1-12 branch off cvs1-12-1.
>
> But I don't see offhand how to track both 1-11 and 1-12 with imports.

I don't see how you don't see.

> At least one of them would have to be put in your repository by
> extracting a tarball on top of a branched sandbox, cvs adding and
> removing, then committing.

You want to manually do what imports were designed for?

> That sounds like a lot of trouble,
> but import would create even more trouble later.

Either way ("manually" or via import), you end up with the
equivalent of a vendor branch, which you can now branch
off, for your own project work.

> > [ . . . ]
> > Strange Thing 2: The join of cvs1-12-2 came up with "has
> > been added" causing a subsequent loss of code because Derek
> > actually added some comments to your submission.
>
> Yep.  That's a bug.  A design bug in update, not in import.

Correct.  There's a separate design anomaly in import.  Imports
shouldn't be creating live heads.  Especially experimental
branches received as a tarball from somewhere.

> > Strange Thing 3: People are perplexed why you don't use the
> > [HEAD],
> > while as far as you can tell, you've set everything up in
> > the most logical manner possible.
>
> Yes, what seems logical doesn't always work.  I think this is CVS' fault,
> not yours:  it doesn't present a really good abstraction of the underlying
> mechanisms.  It's just "good", not "really good" and as a result you
> have to keep some of the low-level details in the back of your mind.
> That stretches the learning curve.

It's certainly very complex from a CM point of view, but that's
why we have CM-type people.  Better the CM person has to do
his job properly than watching programmers lose code and then
get scapegoated because of that (not actually helping the company
at all, no matter how much you succeed in lowering morale).

Now, from a programmer's point of view, it's pretty foolproof.
If they get the cvs checkout command right once, then all the
other commands don't need a branch specified, so not even
programmers can stuff it up.  Except for "cvs log" anyway,
but strictly speaking, they don't NEED to specify the branch,
it's just that they confuse themselves if they don't.

Can you imagine what sort of version numbers I have?  :-)
1.1.325.1.2.17, 1.1.325.1.2.18 etc.

The programmers had a bit of a whinge about why are my
version numbers so big, in other places the numbers were
much simpler.  One of them was smart enough to add
"maybe they didn't use it to the full extent that you do".  :-)

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

BFN.  Paul.