info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Importing vendor update without 1.1.1 branch


From: Kenn Humborg
Subject: Re: Importing vendor update without 1.1.1 branch
Date: Sat, 6 Jan 2001 00:01:49 +0000

On Fri, Jan 05, 2001 at 04:12:23PM -0500, Eric Siegerman wrote:
> 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.)

Unfortunately, I was still under the impression that pretty much
anything in a version control system should be undoable...

Nice way to be enlightened :-)

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

It's hosted at SourceForge so I don't have access to the ,v files.

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

But before the first import, the "vendor" tag referred to 2.2.14.
So shouldn't that have failed the same way?

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

More likely to be one of these, I think.

I'm going to ask SourceForge if they can pull a backup from tape.
If so, I'll try importing it the right way first time and see
if that works.  If not, then I'll wipe it and rebuild it.

Thanks for your help.

Later,
Kenn




reply via email to

[Prev in Thread] Current Thread [Next in Thread]