Re: Importing vendor update without 1.1.1 branch

[Eric Siegerman]

On Fri, Jan 05, 2001 at 01:48:32AM +0000, Kenn Humborg wrote:
> Starting with an empty CVS tree, we did
> 
>    cvs import -b 2.2.14 module vendor vendor-2-2
> [...]
> We continued development, adding files and modifying a few
> vendor files.
> 
> Now I'm trying to import an updated vendor tree [...]:
>    cvs import module vendor vendor-2-4
> 
> New files in vendor-2-4 that were not in vendor-2-2 were added
> at version 1.1.1.1 and updated files were not added because branch
> 1.1.1 cannot be found.  Oops!  It tried to create a 1.1.1 vendor
> branch.

I've scrambled enough repositories that I've come to think of
importing as a dangerous operation -- dangerous enough to be
worth backing up the repository first.  (Not that I'm scrupulous
about actually doing this, alas; there've been times I didn't
bother, and regretted my laziness.)

Since this is the state you're in now...

> So I rig up a script to get the names of these new files 
> and use cvs admin -o 1.1.1: to clear everything out of this 1.1.1
> branch.

I'd have just deleted the ,v files.  For these particular files,
the only revision being lost is the one you're about to replace
with the next attempt at importing.  (Other files have revision
history that you don't want to lose, of course, but those files
don't need to be cleaned up.)

> Of course, I should have specified that the vendor branch is 2.2.14.
> So I tried again:
> 
>    cvs import -b 2.2.14 module vendor vendor-2-4
> 
> This time, updated files are imported OK at version 2.2.14.2,
> but new files are not added:
> 
>    cvs server: /cvsroot/proj/module/file,v: can't find branch point 2.2
>    cvs server: ERROR: Check-in of /cvsroot/proj/module/file,v failed
> 
> Is this because 2.2.14 appeared "out of nowhere"?

Not likely; after all, the same command worked on the vendor-2-2
import, when 2.2.14 was coming equally "out of nowhere".  I
rather suspect that this error is because of one or more of the
following:
  - the files still have a "vendor" tag referring to the 1.1.1
    branch, which conflicts with the new import command's request
    to assign that tag to branch 2.2.14

  - deleting the 1.1.1.1 revisions left the ,v files in an
    inconsistent state (the "vendor-2-4" release tag still
    exists, even though the revision it refers to has vanished)

  - the files now have no revisions at all -- you deleted the
    only one there was

This is why deleting the offending files is the better choice.

> Is there any hope for this tree?  Would I be better off re-creating it
> from scratch (and living with the loss of history info)?

Depends partly on what's happened since, I suppose.  Have people
continued doing commits?  If they have, you'll want to check,
before deleting those bad ,v files, that nobody's committed trunk
revisions to them.

> Are there tools that can extract all the diffs and comments at each
> commit and "replay" them into a new tree to rebuild the history?

Not that I know of.  There sure have been times I've wanted
one...

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense.  But I'm a Sagittarius,
so I'm naturally skeptical.