Re: git copies of cvs modules available

[David Holland <dholland-current%netbsd.org@localhost>]

On Sun, Dec 06, 2009 at 06:02:57PM -0500, Greg A. Woods wrote:
 >>> For example with src/games/hunt/Makefile there's some really bizarre
 >>> confusion w.r.t. the vendor branch -- it is in an impossible state.
 >>> (revision 1.1 and revision 1.1.1.1 MUST always be identical!)
 >> 
 >> This is not true. The state of hunt/Makefile is what you get if you
 >> cvs add and commit version 1.1, and then later on do a cvs import of
 >> the same file
 > 
 > You are not supposed to do that kind of thing with CVS though -- at
 > least not so long as you expect things to continue to work "properly".

Well, yes and no; it's a perfectly reasonable thing to do, and if CVS
leaves an invalid state behind it's a(nother) flaw in CVS.

 > CVS "vendor branch" directories are very tricky in their subtle details.
 > 
 > I.e. when I stated that rev. 1.1 and rev. 1.1.1.1 "MUST" always be
 > identical I was stating a condition that's required for correct
 > behaviour of CVS for some operations.
 > 
 > Sure, you can create that mess with CVS (perhaps if you do things
 > backwards, as you suggest they were done) but the result you get is not
 > going to be usable in all of the ways you might expect it to be.

I'm not sure. I don't think we've ever had any particular problems
with hunt's makefile (other than this conversion issue) and I've had
similar things in other trees without particular problems.

Specifically, it's fairly common in practice, if someone who doesn't
quite know what they're doing commits something with cvs add that
should have been imported, to import a copy under the added version so
things will work usefully when it's time to import a new version...
and in this case at least things do work usefully later.

 > Furthermore the merge after import is _necessary_ if there have ever
 > been any local commits to any files -- an import without a merge is
 > unfinished and leaves the entire module in a poorly defined state.

Yes; the case found in hunt's makefile arises when you run the merge,
and find that there's nothing from the merge to commit.

I wouldn't characterize it as a "poorly defined" state; it's a state
where files with no local branch have been updated and the others
have, which is though an *inconsistent* state perfectly well defined.

-- 
David A. Holland
dholland%netbsd.org@localhost