Re: Importing vendor update without 1.1.1 branch
On Sat, Jan 06, 2001 at 12:01:49AM +, Kenn Humborg wrote: > 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 > > Unfortunately, I was still under the impression that pretty much > anything in a version control system should be undoable... > > Nice way to be enlightened :-) 1. Well, it is. Just not easily. 2. Anything you do to your sandbox is pretty easily recoverable. Some of the things you might do to your repository are a different story. 3. Welcome to CVS. Consider this a wart. > > I'd have just deleted the ,v files. > > It's hosted at SourceForge so I don't have access to the ,v files. Bleah :-( > > > 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? Nope. CVS has no *global* idea of what a given tag means; each file has its own idea (tags and their values are stored separately in each ",v" file, not in some global database). So every file that existed in the vendor-2-2 import has: Tag Value Where it came from -- -- vendor 2.2.14 (b) import of 2.2 vendor-2-2 2.2.14.1 (r)import of 2.2 vendor-2-4 2.2.14.2 (r)second import of 2.4 But every file that didn't exist in 2.2 has: vendor 1.1.1 (b) first import of 2.4 vendor-2-4 1.1.1.1 (r) first import of 2.4 Those tags remain in the ,v file even if you delete revision 1.1.1.1 out from under them; you have to explicitly remove the tags. Do a "cvs log" of a file in each state, and you'll see what I mean. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / 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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Importing vendor update without 1.1.1 branch
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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Importing vendor update without 1.1.1 branch
On Fri, Jan 05, 2001 at 01:48:32AM +, 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.[EMAIL PROTECTED] | | / 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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
