Re: import inconsistency

[Pierre Asselin]

Paul Edwards <kerravon@nosppaam.w3.to> wrote:

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


> So you have two vendor branches, with the above names.
> No head yet.

The support for multiple vendor branches is very weak.  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.


> 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, even if you haven't made any
changes yet, or files won't die that should have.


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


> 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.  You keep
coding on the old base, or you merge your branch to the up-to-date stuff
and kill it, 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.

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

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


> 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.
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.  That sounds like a lot of trouble,
but import would create even more trouble later.

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


> Strange Thing 3: People are perplexed why you don't use the
> Attic, 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.