From justin.love at cesgames.com Wed Aug 1 15:49:38 2007 From: justin.love at cesgames.com (Justin Love) Date: Wed Aug 1 15:51:49 2007 Subject: Missing VSS ADD records Message-ID: <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> Hello, I've been looking at switching us over to SVN. vss2svn recovered way more history than the other systems I looked at. Good work guys! However, I ran into my own little piece of corruption. A few of my files, which we have had trouble with in the past, didn't have the file ADD records to supply a v1 version number. Almost everything in vss2svn checks for a version number before proceeding, so the files were completely missing from the export. I have a patch that restored my missing files by fabricating the missing records with the first version available; I leave incorporation to people who might understand other side effects better. Beyond that, there were a couple missing files from an old project, where I am satisfying myself with checking in the latest copy, and one case where I intentionally took a file to zero size, (and vss2svn didn't include that version) also corrected by a checkin. -------------- next part -------------- A non-text attachment was scrubbed... Name: vss2svn.diff Type: application/octet-stream Size: 1953 bytes Desc: not available Url : http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20070801/1d5678f0/vss2svn.obj -------------- next part -------------- Justin Love Creative Electronics & Software 650 Sundown Road South Elgin, IL 60177 Phone (847) 695-0023 FAX (847) 695 0483 From justin.love at cesgames.com Wed Aug 1 15:43:16 2007 From: justin.love at cesgames.com (Justin Love) Date: Wed Aug 1 15:51:53 2007 Subject: Newline translation Message-ID: <5.0.2.1.2.20070801143256.00c4b858@mail.cesgames.com> I updated vss2svn after trying it a few weeks earlier, and found that all my files had gotten newline-converted. I believe the problem is an errant 'defined' when deciding whether to do the conversion. 0 is defined but still false. -------------- next part -------------- A non-text attachment was scrubbed... Name: dumpfile.diff Type: application/octet-stream Size: 468 bytes Desc: not available Url : http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20070801/5473805b/dumpfile.obj -------------- next part -------------- Justin Love Creative Electronics & Software 650 Sundown Road South Elgin, IL 60177 Phone (847) 695-0023 FAX (847) 695 0483 From vss2svn at nogga.de Fri Aug 3 04:40:33 2007 From: vss2svn at nogga.de (Dirk) Date: Fri Aug 3 04:42:45 2007 Subject: Newline translation In-Reply-To: <5.0.2.1.2.20070801143256.00c4b858@mail.cesgames.com> References: <5.0.2.1.2.20070801143256.00c4b858@mail.cesgames.com> Message-ID: <46B2EA01.9090804@nogga.de> Hi Justin, thanks for the patch. I have comitted it in r324. Dirk From vss2svn at nogga.de Fri Aug 3 05:29:39 2007 From: vss2svn at nogga.de (Dirk) Date: Fri Aug 3 05:31:52 2007 Subject: Missing VSS ADD records In-Reply-To: <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> References: <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> Message-ID: <46B2F583.5070606@nogga.de> Hi justin, Justin Love schrieb: > Hello, I've been looking at switching us over to SVN. vss2svn > recovered way more history than the other systems I looked at. Good > work guys! Thanks for using the code and it seems that it helped you also. > > However, I ran into my own little piece of corruption. A few of my > files, which we have had trouble with in the past, didn't have the > file ADD records to supply a v1 version number. Almost everything in > vss2svn checks for a version number before proceeding, so the files > were completely missing from the export. I have a patch that restored > my missing files by fabricating the missing records with the first > version available; I leave incorporation to people who might > understand other side effects better. > Intersting problem and an intersting patch. I currently can not fully understand, how this can happen, but the idea is not bad. I have to investigate this a little further. Can ouy send me the output of ssphys of one of these problematic files? I'm wondering how the ADD record is missing. > Beyond that, there were a couple missing files from an old project, > where I am satisfying myself with checking in the latest copy, and one > case where I intentionally took a file to zero size, (and vss2svn > didn't include that version) also corrected by a checkin. Do you know, whether the missing files where part of the conversion? You can check that by calling "ss.exe physical $path/to/file" and then check for the physical name within your vss2svn logs. Is there probably only a missing recover somewhere along the lines? I will have a look where the empty files gets losts. Thanks for the patch Dirk From gillius-ml at gillius.org Fri Aug 3 09:17:13 2007 From: gillius-ml at gillius.org (Jason Winnebeck) Date: Fri Aug 3 09:17:27 2007 Subject: Missing VSS Files: Rollback Problems? Message-ID: <46B32AD9.9050800@gillius.org> I've been watching the "Missing VSS ADD" thread, and I don't think I reported this but not all of my files came through the final export either, but for a different reason. I actually thought that it NEVER came out, but that's not exactly true. I really don't know what happened to this file but it is certainly interesting, and it seems to have something to do with a rollback. Vss2svn picked up several revisions, then it was deleted, as shown below: Deleted at revision 9228 B/Name2.java (edit) [9081] 3/16/2006 9:58 (edit) [8979] 3/1/2006 11:11 (edit) [8957] 2/28/2006 15:50 (copy) [8953] 2/28/2006 14:38 copied from B/Name1.java: (copy) [8951] 2/28/2006 14:38 copied from A/Name1.java: (edit) [8893] 2/27/2006 8:52 (add) [8882] 2/23/2006 14:17 The double copy is actually a single move, but it must show up in VSS as a move to a new path, then a rename to the new name. In SourceSafe, it shows 5 revisions since creation, with a rollback at version 5, to version 5. If you look at version 5 in SS it actually shows the content for version 4. Also, revision 9081 that took place at 3/16/2006 can't be seen in SS (it would be the actual version 5). In a weird way if you look in properties it shows the file as if it were branched then the original branch was deleted. I think this might happen in SourceSafe when you rollback more than 1 version (i.e. more than the last change), but I can't confirm that. In SourceSafe, the file takes modifications after 9228, but vss2svn shows a delete, so there's no file to modify. Maybe it drops the bad modifies? I have the physical files and I can run ssphys on it but I'm not sure what to run that might be helpful, although this seems weird: $ vss/run/ssphys history kehaaaaa $ vss/run/ssphys validate kehaaaaa WARNING: unknown combination of flags in the FileInfo record: 0x100 vss/run/ssphys: could not read record at offset behind file size Jason From justin.love at cesgames.com Fri Aug 3 09:56:38 2007 From: justin.love at cesgames.com (Justin Love) Date: Fri Aug 3 09:56:12 2007 Subject: Missing VSS ADD records In-Reply-To: <46B2F583.5070606@nogga.de> References: <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> Message-ID: <5.0.2.1.2.20070803083039.00bdb7b8@mail.cesgames.com> >Intersting problem and an intersting patch. I currently can not fully >understand, how this can happen, but the idea is not bad. I have to >investigate this a little further. Can ouy send me the output of ssphys of >one of these problematic files? I'm wondering how the ADD record is missing. 'ssphys info'? Attached. V1 of this file is also inaccessible in Sourcesafe. >Do you know, whether the missing files where part of the conversion? >You can check that by calling "ss.exe physical $path/to/file" and then >check for the physical name within your vss2svn logs. Is there probably >only a missing recover somewhere along the lines? Physical file names from both cases appear in the logs, with no obvious errors. The project with missing files is old enough that I'm satisfied with the latest version, so I didn't investigate. With a brief look, it appears that the affected files were added but never changed. (So I'm not loosing much in the way of history anyway.) The zero size file is a slightly odd practice, and I could see it as a valid exclusion in case VSS lost some data. If you've got some specific test you'd like me to run, let me know. -------------- next part -------------- A non-text attachment was scrubbed... Name: vjiaaaaa.xml Type: application/xml Size: 21562 bytes Desc: not available Url : http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20070803/f0616010/vjiaaaaa-0001.rdf -------------- next part -------------- Justin Love Creative Electronics & Software 650 Sundown Road South Elgin, IL 60177 Phone (847) 695-0023 FAX (847) 695 0483 From MKCline at hotmail.com Sat Aug 4 10:48:14 2007 From: MKCline at hotmail.com (Michael Cline) Date: Sat Aug 4 10:48:24 2007 Subject: Binary Files were corrupt Message-ID: I recently ran the the nightly build from 20070719 and upon the end of the conversion when I was verifying the converted files with the original files I found that most all of my binary files had differences. Specific extensions that had issue were: dll pdb swf pdf png exe I had other files which didn't have a problem ico jpg gif doc and an occasional swf the auto-props settings for these files are as follows (the properties appear to be set correctly, it is as if the export or import *.dll = svn:mime-type=application/octet-stream *.pdb = svn:mime-type=application/octet-stream *.swf = svn:mime-type=application/x-shockwave-flash *.pdf = svn:mime-type=application/pdf *.png = svn:mime-type=image/png *.exe = svn:mime-type=application/octet-stream;svn:executable I noticed the 20070803 build had some auto-props mention in it but didn't necessarily look related. The command line I am running is: vss2svn --vssdir "PATH" --auto_props="C:\data\tools\config" --revtimerange 60 Is this a user error on my part? Thanks, Michael Cline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20070804/9208db6f/attachment.html From MKCline at hotmail.com Sat Aug 4 23:28:37 2007 From: MKCline at hotmail.com (Michael Cline) Date: Sat Aug 4 23:28:49 2007 Subject: Binary Files were corrupt Message-ID: Looks like the latest build 0803 resolved this issue. Michael Cline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20070804/c3713486/attachment.html From vss2svn at nogga.de Mon Aug 6 12:19:27 2007 From: vss2svn at nogga.de (Dirk) Date: Mon Aug 6 12:21:39 2007 Subject: Binary Files were corrupt In-Reply-To: References: Message-ID: <46B74A0F.7050202@nogga.de> > > Looks like the latest build 0803 resolved this issue. Sorry, that was my fault. I felt into the same issue just at the day, when I finally switched over to subversion. Hurray... 2 1/2 years after I had started ;-) with ssphys and vss2svn. Dirk From vss2svn at nogga.de Mon Aug 6 17:40:06 2007 From: vss2svn at nogga.de (Dirk) Date: Mon Aug 6 17:46:27 2007 Subject: Missing VSS ADD records In-Reply-To: <5.0.2.1.2.20070803083039.00bdb7b8@mail.cesgames.com> References: <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> <5.0.2.1.2.20070803083039.00bdb7b8@mail.cesgames.com> Message-ID: <46B79536.6070307@nogga.de> Justin Love schrieb: > >> Intersting problem and an intersting patch. I currently can not fully >> understand, how this can happen, but the idea is not bad. I have to >> investigate this a little further. Can ouy send me the output of >> ssphys of one of these problematic files? I'm wondering how the ADD >> record is missing. > > 'ssphys info'? Attached. V1 of this file is also inaccessible in > Sourcesafe. Looking into the XML file you can see a strange "offset" jump within the first records: 1.) ItemInfo offset ="52" 2.) Checkout offset = "416" 3.) ParentFolder offset = "1092" 4.) Version offset = "42704" <=== All data in the physical files is recorded in blocks of specific records. Each block has a header with the size of the block, an identifier for the block type and a checksum. ssphys will read record by record depending on the size of each record. There are two types of problems: 1.) The recorded size in the header is wrong: ssphys will read to many bytes and needs to resync until it finds a valid record header again 2.) The records are "broken" and will contain an undecodeable block type or the checksum is broken. Without checking, I expected that you had seen an error message in this case. Another possibility would be, that the file was broken and that analyze fixed the files in a way, that it "removed" the problematic records by introducing a large empty block. In order to analyze this, I need to have the physical file itself. Since we are now missing version 1, which is the add record, ssphys will go crazy. Your patch is the best solution for this problem. >> Do you know, whether the missing files where part of the conversion? >> You can check that by calling "ss.exe physical $path/to/file" and >> then check for the physical name within your vss2svn logs. Is there >> probably only a missing recover somewhere along the lines? > > Physical file names from both cases appear in the logs, with no > obvious errors. The project with missing files is old enough that I'm > satisfied with the latest version, so I didn't investigate. With a > brief look, it appears that the affected files were added but never > changed. This is still strange. Esp. in case that he files where never changed, if they where added, but not deleted, they must be part of the converted archive. Have you checked, whether they come out in the orphaned cache? From vss2svn at nogga.de Mon Aug 6 18:29:23 2007 From: vss2svn at nogga.de (Dirk) Date: Mon Aug 6 18:35:24 2007 Subject: Missing VSS Files: Rollback Problems? In-Reply-To: <46B32AD9.9050800@gillius.org> References: <46B32AD9.9050800@gillius.org> Message-ID: <46B7A0C3.7040007@nogga.de> Hello Jason: > I've been watching the "Missing VSS ADD" thread, and I don't think I > reported this but not all of my files came through the final export > either, but for a different reason. I actually thought that it NEVER > came out, but that's not exactly true. I really don't know what > happened to this file but it is certainly interesting, and it seems to > have something to do with a rollback. thanks for your comments. Actually the rollback record is the corresponding action to a branch. If the file that you are "rolling back" is not involved in any other share, then the rollback will simply delete all versions. That means: If you have a simple, non shared file, there is no problem with a rollback. You will not see any events in the history after rolling back. On the other hand, if the file is shared, the share will use the "younger revisions" hat you are trying to delete. rolling back this file will silently branch the file in the background at the version that you selected for the rollback activity. in order to keep the share alive. The problem seems to be, that this "automatic branch" is not recorded in the parent. So there is no corresponding "branch" record. Rollback and Branch records are norally merged together to find the necessary Parent / Child information . If we only have a "Rollback" record, I do't know what will happen. I have to investigate this further. Dirk From gillius-ml at gillius.org Mon Aug 6 23:24:07 2007 From: gillius-ml at gillius.org (Jason Winnebeck) Date: Mon Aug 6 23:24:12 2007 Subject: Missing VSS Files: Rollback Problems? In-Reply-To: <46B7A0C3.7040007@nogga.de> References: <46B32AD9.9050800@gillius.org> <46B7A0C3.7040007@nogga.de> Message-ID: <46B7E5D7.6000407@gillius.org> The weird thing is that as far as I know the file was never shared. I wonder if it was renamed or moved, and moving is done as a share + delete. But in the links tab, no other links were shown, so if there was a branch I couldn't find it. If you think that's unlikely I could check back again in depth. I haven't used branches so maybe if you branch it doesn't show up in links anymore. Jason Dirk wrote: > On the other hand, if the file is shared, > the share will use the "younger revisions" hat you are trying to delete. > rolling back this file will silently branch the file in the background > at the version that you selected for the rollback activity. From justin.love at cesgames.com Wed Aug 8 10:29:12 2007 From: justin.love at cesgames.com (Justin Love) Date: Wed Aug 8 10:28:43 2007 Subject: Missing VSS ADD records In-Reply-To: <46B79536.6070307@nogga.de> References: <5.0.2.1.2.20070803083039.00bdb7b8@mail.cesgames.com> <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> <5.0.2.1.2.20070801143842.02202d70@mail.cesgames.com> <5.0.2.1.2.20070803083039.00bdb7b8@mail.cesgames.com> Message-ID: <5.0.2.1.2.20070808092206.00c1ec80@mail.cesgames.com> > >Another possibility would be, that the file was broken and that analyze >fixed the files in a way, that it "removed" the problematic records by >introducing a large As I said, these files had errors a few years ago; we ran multiple rounds of 'analyze' and eventually switched to a different project directory in sourcesafe (which later got renamed back to the original.) During analyze runs one of the files still reports an error indicating early revisions will be unaccessible. >This is still strange. Esp. in case that he files where never changed, if >they where added, but not deleted, they must be part of the converted >archive. Have you checked, whether they come out in the orphaned cache? I ran this to no avail: grep -i orphan vss2svn-dumpfile.dat What should I in fact be looking for? Justin Love Creative Electronics & Software 650 Sundown Road South Elgin, IL 60177 Phone (847) 695-0023 FAX (847) 695 0483 From toby at etjohnson.us Wed Aug 15 18:13:02 2007 From: toby at etjohnson.us (Toby Johnson) Date: Wed Aug 15 18:13:05 2007 Subject: Complex VSS Migration - dealing with moved/branched version history In-Reply-To: <53F4EE95A373AB4887E261A376BC130DE02816@AD1HFDEXC306.ad1.prod> References: <53F4EE95A373AB4887E261A376BC130DE02816@AD1HFDEXC306.ad1.prod> Message-ID: <46C37A6E.1070106@etjohnson.us> FYI, vss2svn is a completely separate project from Subversion; I am copying in that mailing list so please join there (http://www.pumacode.org/projects/vss2svn) to discuss further. See additional comments below... Bicking, David (HHoldings, IT) wrote: > I searched for days for information and tried many options, and now am > standing at a brick wall. > > I am evaluating Subversion as a replacement for VSS. This company has a > huge repository (about 10G) in which branching and sharing were rampant. > Worse, there was no plan for how projects were defined. Consequently, > in addition to the typical VSS corruptions in the data, most projects > (folders) have references to other projects somewhere deep in the > history. > First off, I would take a step back and ask yourself if converting and maintaining all that history is really worth it. I have seen lots of people (including myself) who struggled with migrating a perfect copy of their VSS history only to find out they ended up using it much less than they anticipated. Particularly in your case I would say it sounds like a clean start may be your best option going forward; it may be more inconvenient in the short term but after a few months you'll probably find yourself needing that history very infrequently. Due to the state of your VSS repo it may be better to simply put VSS into read-only mode for reference and then simply export the contents and import to Subversion. You'll still need to deal with all those shares, since that feature does not translate to Subversion, although svn:externals is close enough for many purposes. > I want to migrate pieces of this behemoth into SVN, but cannot. I used > vss2svn to get a dumpfile (12G) and tried to use svndumpfilter to grab > relevant pieces. Per the state of the data described in the prior > paragraph, it fails every time. I found no reference to any way to pull > a specific project "tree" and get all its history, which is quite odd. > I would think this would be crucial. Why not permit migration to pull > the original data into place? A note stating "original location is x" > should be sufficient. > I'm not sure exactly what you're asking here. If you are asking why vss2svn doesn't allow migrating only a portion of the VSS hierarchy instead of the whole thing, the answer to that is rather technical but in a nutshell the way VSS stores its history in "physical files" makes it very difficult to convert only a portion of the repo since the program must essentially walk the entire VSS tree in order to resolve parent-child relationships. Most people who want to do what you are trying to accomplish do use the svndumpfilter approach; if you can provide more specific info as to why that is failing then we may be able to provide a better suggestion or workaround. toby From tr-huso at online.no Thu Aug 30 05:17:07 2007 From: tr-huso at online.no (Trond =?ISO-8859-1?Q?Hus=F8?=) Date: Thu Aug 30 05:17:14 2007 Subject: Sec to small Message-ID: <1188465427.6864.9.camel@d420-thu-ubuntu> Hi List, I?m trying to run vss2svn on a win2000 server and when it runs I get this error: Use of uninitialized value in gmtime at /PerlApp/Vss2Svn/Dumpfile.pm line 904. Sec too small - 0 < 3600 Cannot handle date (0, 0, 0, 1, 0, 1970) at /PerlApp/Vss2Svn/Dumpfile.pm line 905 Best regards, Trond From toby at etjohnson.us Fri Aug 31 10:06:18 2007 From: toby at etjohnson.us (Toby Johnson) Date: Fri Aug 31 10:06:21 2007 Subject: Sec to small In-Reply-To: <1188465427.6864.9.camel@d420-thu-ubuntu> References: <1188465427.6864.9.camel@d420-thu-ubuntu> Message-ID: <46D8205A.1030002@etjohnson.us> Trond Hus? wrote: > Hi List, > I?m trying to run vss2svn on a win2000 server and when it runs I get > this error: > Use of uninitialized value in gmtime at /PerlApp/Vss2Svn/Dumpfile.pm > line 904. > Sec too small - 0 < 3600 > Cannot handle date (0, 0, 0, 1, 0, 1970) at /PerlApp/Vss2Svn/Dumpfile.pm > line 905 > Hello Trond, It looks like there is a problem in one of your VSS files which is causing the script to fail when trying to determine a timestamp. Can you run the script with --debug enabled, and send the last bit of the output before the crash? toby From ChristopherRobinson at fairisaac.com Fri Aug 31 15:36:04 2007 From: ChristopherRobinson at fairisaac.com (Robinson, Christopher H (Chris)) Date: Fri Aug 31 15:36:18 2007 Subject: Having a little trouble with 'vss2svn' on a 'clean' VSS repository Message-ID: <37F7E395D92AAA4D8D6DDDC975DC35690359AFF4@STPMSGMB01.corp.fairisaac.com> Hi, I'm in the midst of migrating of our development teams from VSS, CVS, and ClearCase to Subversion and I'm running into a bit of trouble. I'm starting first with the VSS repositories. I ran the analyze tool on a stable copy of a VSS repository(about 1Gb in size) and the analyze tool reported no errors. I have encountered errors when using analyze on other VSS repositories, but for the repository I'm referring to in this post, the repository was clean. I then ran the vss2svn tool(vss2svn-nightly-20070803.zip ) from my local PC(Windows XP SP2) on the repository and received the following output and error messages: C:\VSS\IDM02>vss2svn -vssdir . Using a hash as a reference is deprecated at /PerlApp/Vss2Svn/Dumpfile.pm line 778. Adding 'C:/DOCUME~1/chr/LOCALS~1/Temp/pdk-chr-6268/encodings' to encodings file path Connecting to database ./_vss2svn/vss_data.db Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 1287. Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 1287. Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 1287. ======== VSS2SVN ======== BEGINNING CONVERSION... Start Time : Fri Aug 31 11:56:44 2007 VSS Dir : . Temp Dir : ./_vss2svn Dumpfile : vss2svn-dumpfile.dat VSS Encoding : windows-1252 Auto Props : trunk dirk : md5 : label dir : /labels label mapper : VSS2SVN ver : 0.11.0-nightly.321 SSPHYS exe : ssphys SSPHYS ver : 0.22.0.275 XML Parser : XML::SAX::Expat TASK: INIT TASK: LOADVSSNAMES WARNING: control character 0x06 in text input at character 10 WARNING: control character 0x06 in text input at character 10 TASK: FINDDBFILES TASK: GETPHYSHIST TASK: MERGEPARENTDATA TASK: MERGEMOVEDATA TASK: REMOVETMPCHECKIN Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 817 . Remove action_id 1700, IOFAAAAA, ADD, Temporary file created by Visual Studio .NET to detect Microsoft Visual S ourceSafe capabilities. Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 817 . . Remove action_id 6899, UUDAAAAA, DELETE, Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 817 . Remove action_id 6900, VUDAAAAA, ADD, Temporary file created by Visual Studio .NET to detect Microsoft Visual S ourceSafe capabilities. Use of uninitialized value in concatenation (.) or string at vss2svn.pl line 817 . Remove action_id 6901, VUDAAAAA, DELETE, TASK: MERGEUNPINPIN TASK: BUILDCOMMENTS TASK: BUILDACTIONHIST ERROR -- Attempt to add entry 'QOAAAAAA' with unknown version number (probably d estroyed) at vss2svn.pl line 1065 ERROR -- Attempt to add entry 'PVBAAAAA' with unknown version number (probably d estroyed) at vss2svn.pl line 1065 ERROR -- Attempt to commit unknown item 'OPAAAAAA': at vss2svn.pl line 1065 ERROR -- Attempt to share unknown item 'LFFAAAAA': TASK: IMPORTSVN Attempt to commit to non-existant file '/orphaned/_ELAAAAAA/IDM Documentation /Designs/Bureau Test Servers - Instructions.doc' at revision 2818, changing to add; possibly missing recover at vss2svn.pl line 1222 ======================================================================== ===== END OF CONVERSION The VSS to SVN conversion is complete. You should now use the "svnadmin load" command to load the generated dumpfile 'vss2svn-dumpfile.dat'. The "svnadmin" utility is provided as part of the Subversion command-line toolset; use a command such as the following: svnadmin load < "vss2svn-dumpfile.dat" You may need to precede this with "svnadmin create " if you have not yet created a repository. Type "svnadmin help " for more information on "create" and/or "load". If any errors occurred during the conversion, they are summarized above. For more information on the vss2svn project, see: http://www.pumacode.org/projects/vss2svn/ Started at : Fri Aug 31 11:56:44 2007 Ended at : Fri Aug 31 12:25:04 2007 Elapsed time : 00:28:20 (H:M:S) VSS Actions read : 7570 SVN Revisions converted : 2819 Date range (YYYY/MM/DD) : 2003/04/30 to 2007/08/09 C:\VSS\IDM02> Despite the error messages, the vss2svn utility completed and generated about a 1Gb dump file. I then tried to load that dump file into a new Subversion repository, and things were going pretty well until it stopped at the following: ------- Committed revision 2516 >>> <<< Started new transaction, based on original revision 2517 * adding path : labels/Idm_1.1.1.5 ... done. * adding path : labels/Idm_1.1.1.5/orphaned ... done. * adding path : labels/Idm_1.1.1.5/orphaned/_POAAAAAA ... done. * adding path : labels/Idm_1.1.1.5/orphaned/_POAAAAAA/IDM Sourcecode ...COPIED... done. * adding path : labels/Idm_1.1.1.5/orphaned/_POAAAAAA/IDM Sourcecode ...COPIED... done. svnadmin: Invalid change ordering: new node revision ID without delete Considering that the analyze tool reported not a single error in this VSS repository, any ideas what my next steps should be? Any feedback is greatly appreciated. Chris Robinson Configuration Management Fair Isaac Corporation ChristopherRobinson@fairisaac.com This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20070831/071e9d4b/attachment-0001.html