From eugen_eugen at gmx.de Fri Feb 1 04:58:27 2008 From: eugen_eugen at gmx.de (Jewgenij Moldawski) Date: Fri Feb 1 04:58:35 2008 Subject: Why orphaned? Message-ID: <20080201095827.62790@gmx.net> Dear friends, I'm now testing the vss2svn (as .exe program, not .pl) and migrating a very small (some MBs) VSS test-repository, Version 6.0. The vss2svn reports first "Warning: Unknown Action RestoreProject". After the migration and after I loaded the dump file into Subversion, I see, that all but entire VSS-content is now under /orphaned in Subversion. Can the warning above be related to files that were being orphaned during the migration? What can I do to avoid that files will being orphaned? I've already seen some discussions about "orphaned" on PUMACODE, but I couldn't match it to my situation. I'm not very familiar with VSS and would be grateful for Your help. Thanks! -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From Stephen.Lee at hexagonmetrology.com Fri Feb 1 05:40:08 2008 From: Stephen.Lee at hexagonmetrology.com (Stephen Lee) Date: Fri Feb 1 05:41:23 2008 Subject: Why orphaned? In-Reply-To: <20080201095827.62790@gmx.net> References: <20080201095827.62790@gmx.net> Message-ID: <47A2F708.2020009@hexagonmetrology.com> Jewgenij Moldawski wrote: > > Dear friends, > > I'm now testing the vss2svn (as .exe program, not .pl) and migrating a > very small (some MBs) VSS test-repository, Version 6.0. > > The vss2svn reports first "Warning: Unknown Action RestoreProject". > After the migration and after I loaded the dump file into Subversion, > I see, that all but entire VSS-content is now under /orphaned in > Subversion. > You probably created your test repository by exporting a project and importing this into a test database... vss2svn doesn't work very well like that - you're better off with a SourceSafe database that doesn't have archive/restore actions in its history. If necessary due to large database size, destroy all except the project you want to test with on a backup of the database and to a test conversion on that. Also the Alpha that looks like its the one you want is very old and very fragile, and doesn't cope well with any "complicated" actions on files or projects. Many of the "nightly" builds are much more stable and reliable in my experience, particularly for SourceSafe databases that have had anything other than a trivial version history. -- Stephen Lee Software Engineer, Vision Group - Pro-Measure Leader Wilcox Associates Inc. (U.K.) From jd_hardcastle at yahoo.com Fri Feb 1 06:02:30 2008 From: jd_hardcastle at yahoo.com (Jon Hardcastle) Date: Fri Feb 1 06:02:40 2008 Subject: Why orphaned? In-Reply-To: <47A2F708.2020009@hexagonmetrology.com> Message-ID: <856675.6291.qm@web51303.mail.re2.yahoo.com> --- Stephen Lee wrote: > Jewgenij Moldawski wrote: > > > > Dear friends, > > > > I'm now testing the vss2svn (as .exe program, not > .pl) and migrating a > > very small (some MBs) VSS test-repository, Version > 6.0. > > > > The vss2svn reports first "Warning: Unknown Action > RestoreProject". > > After the migration and after I loaded the dump > file into Subversion, > > I see, that all but entire VSS-content is now > under /orphaned in > > Subversion. > > > > You probably created your test repository by > exporting a project and > importing this into a test database... vss2svn > doesn't work very well > like that - you're better off with a SourceSafe > database that doesn't > have archive/restore actions in its history. If > necessary due to large > database size, destroy all except the project you > want to test with on a > backup of the database and to a test conversion on > that. > > Also the Alpha that looks like its the one you want > is very old and very > fragile, and doesn't cope well with any > "complicated" actions on files > or projects. Many of the "nightly" builds are much > more stable and > reliable in my experience, particularly for > SourceSafe databases that > have had anything other than a trivial version > history. Just as a second to what this chap replied with - I have just finished (well 2months ago) migrating several repositories with chequered histories at best.. and all quite large.. I got the best sucess when i did the following. Keep running VSS analysis until it complains no more. Sometimes you have to delete files of 0 bytes to obtain this. Purge all deleted files from the VSS repository. Run the migrate on the latest nightly (which is quite old) it is much better at histories and generally. Create your SVN repos.. and attempt an import. In my experience it kept falling over on the import back in. My cut and burn solution to this was to delete delete the file that caused the problem IN SOURCE SAFE. I also found that if 1 file in a dir complained it was likely several would - save yourself some time. if non of the histories to these files are import purge the directory containing them.. Repeat until you can migrate, and import without error. Then you overlay VSS with SVN by checking out the head of each and copying the VSS over the SVN stuff. The files that are identical will change nothing. new or changed files can be committed here. also - learn from my mistake and consider any file properties you might use.. like SVN needs lock and apply it NOW.. here.. use the python script called something like svn_auto_prop.py. Then update everyone's tortoise file (if that is what your using) to match these settings for new files. I can furnish you with a comprehensive one if you so care. Hope this helps. ----------------------- N: Jon Hardcastle E: Jon@eHardcastle.com 'The writing is on the wall...' ----------------------- From nathan-svn at spicycrypto.ca Fri Feb 1 11:11:17 2008 From: nathan-svn at spicycrypto.ca (Nathan Kidd) Date: Fri Feb 1 11:11:35 2008 Subject: Why orphaned? In-Reply-To: <856675.6291.qm@web51303.mail.re2.yahoo.com> References: <856675.6291.qm@web51303.mail.re2.yahoo.com> Message-ID: <47A344A5.4030706@spicycrypto.ca> Jon Hardcastle wrote: > Just as a second to what this chap replied with - I > have just finished (well 2months ago) migrating > several repositories with chequered histories at > best.. and all quite large.. I got the best sucess > when i did the following. ... > Create your SVN repos.. and attempt an import. In my > experience it kept falling over on the import back in. > > My cut and burn solution to this was to delete delete > the file that caused the problem IN SOURCE SAFE. I > also found that if 1 file in a dir complained it was > likely several would - save yourself some time. if non > of the histories to these files are import purge the > directory containing them.. > > Repeat until you can migrate, and import without > error. In the recent conversion I did I found it fairly easy to : 1. svnamin load, observe on which revision it fails 2. 'svndumptool split' [1] the failing revision out of the main dumpfile such that you get A.dump (revisions before bad rev), B.dump (the bad revision) and C.dump (revisions after bad rev). 3. Open B.dump in your favourite editor that won't mangle binary data (vi!) and fix it. (Does a parent directory need to be created? Is a rename wrong? Forcibly "un-orphan" a file by reconnecting its path to its true parent, etc.) The format is pretty easy to work with if you're careful -- just copy an entry similar to what you want and tweak. 4. svnadmin load A.dump, B.dump, C.dump 5. Goto 1, for any problem in C.dump. I found this much faster than trying to change something in the vss2svn process, and it guaranteed working results. -Nathan [1] http://svn.borg.ch/svndumptool/ From jd_hardcastle at yahoo.com Fri Feb 1 11:15:39 2008 From: jd_hardcastle at yahoo.com (Jon Hardcastle) Date: Fri Feb 1 11:15:44 2008 Subject: Why orphaned? In-Reply-To: <47A344A5.4030706@spicycrypto.ca> Message-ID: <734514.66296.qm@web51311.mail.re2.yahoo.com> 2 things.. 1) Show off! :) 2) Where were you 2months ago when i needed advise like that! ;) --- Nathan Kidd wrote: > Jon Hardcastle wrote: > > Just as a second to what this chap replied with - > I > > have just finished (well 2months ago) migrating > > several repositories with chequered histories at > > best.. and all quite large.. I got the best sucess > > when i did the following. > > ... > > Create your SVN repos.. and attempt an import. In > my > > experience it kept falling over on the import back > in. > > > > My cut and burn solution to this was to delete > delete > > the file that caused the problem IN SOURCE SAFE. I > > also found that if 1 file in a dir complained it > was > > likely several would - save yourself some time. if > non > > of the histories to these files are import purge > the > > directory containing them.. > > > > Repeat until you can migrate, and import without > > error. > > In the recent conversion I did I found it fairly > easy to : > > 1. svnamin load, observe on which revision it fails > 2. 'svndumptool split' [1] the failing revision out > of the main dumpfile > such that you get A.dump (revisions before bad rev), > B.dump (the bad > revision) and C.dump (revisions after bad rev). > 3. Open B.dump in your favourite editor that won't > mangle binary data > (vi!) and fix it. (Does a parent directory need to > be created? Is a > rename wrong? Forcibly "un-orphan" a file by > reconnecting its path to > its true parent, etc.) The format is pretty easy to > work with if you're > careful -- just copy an entry similar to what you > want and tweak. > 4. svnadmin load A.dump, B.dump, C.dump > 5. Goto 1, for any problem in C.dump. > > I found this much faster than trying to change > something in the vss2svn > process, and it guaranteed working results. > > -Nathan > > [1] http://svn.borg.ch/svndumptool/ > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable > archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > ----------------------- N: Jon Hardcastle E: Jon@eHardcastle.com 'The writing is on the wall...' ----------------------- From Aaron.Larson at Honeywell.com Fri Feb 1 11:28:33 2008 From: Aaron.Larson at Honeywell.com (Larson, Aaron (SWCOE)) Date: Fri Feb 1 11:28:17 2008 Subject: Why orphaned? In-Reply-To: <734514.66296.qm@web51311.mail.re2.yahoo.com> Message-ID: I agree with Jon. I spent weeks trying to get some of our repositories converted, and eventually just gave up (way too much corruption). In retrospect, we haven't used them all that much anyway, but when we do need them it is a serious pain to get back to the data. I assume svndumptool refers to: http://www.tonotono.net/ua/nph-.cgi/000000A/http/svn.borg.ch/svndumptool/ If so, then this little tidbit seems like a good addition to http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration#Loadthedumpfileintotherepository What say the vss2svn wizards? -----Original Message----- From: vss2svn-users-bounces@lists.pumacode.org [mailto:vss2svn-users-bounces@lists.pumacode.org] On Behalf Of Jon Hardcastle Sent: Friday, February 01, 2008 10:16 AM To: Vss2Svn Users Subject: Re: Why orphaned? 2 things.. 1) Show off! :) 2) Where were you 2months ago when i needed advise like that! ;) --- Nathan Kidd wrote: > Jon Hardcastle wrote: > > Just as a second to what this chap replied with - > I > > have just finished (well 2months ago) migrating > > several repositories with chequered histories at > > best.. and all quite large.. I got the best sucess > > when i did the following. > > ... > > Create your SVN repos.. and attempt an import. In > my > > experience it kept falling over on the import back > in. > > > > My cut and burn solution to this was to delete > delete > > the file that caused the problem IN SOURCE SAFE. I > > also found that if 1 file in a dir complained it > was > > likely several would - save yourself some time. if > non > > of the histories to these files are import purge > the > > directory containing them.. > > > > Repeat until you can migrate, and import without > > error. > > In the recent conversion I did I found it fairly > easy to : > > 1. svnamin load, observe on which revision it fails > 2. 'svndumptool split' [1] the failing revision out > of the main dumpfile > such that you get A.dump (revisions before bad rev), > B.dump (the bad > revision) and C.dump (revisions after bad rev). > 3. Open B.dump in your favourite editor that won't > mangle binary data > (vi!) and fix it. (Does a parent directory need to > be created? Is a > rename wrong? Forcibly "un-orphan" a file by > reconnecting its path to > its true parent, etc.) The format is pretty easy to > work with if you're > careful -- just copy an entry similar to what you > want and tweak. > 4. svnadmin load A.dump, B.dump, C.dump > 5. Goto 1, for any problem in C.dump. > > I found this much faster than trying to change > something in the vss2svn > process, and it guaranteed working results. > > -Nathan > > [1] http://svn.borg.ch/svndumptool/ > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable > archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > ----------------------- N: Jon Hardcastle E: Jon@eHardcastle.com 'The writing is on the wall...' ----------------------- _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user From nathan-svn at spicycrypto.ca Fri Feb 1 11:29:57 2008 From: nathan-svn at spicycrypto.ca (Nathan Kidd) Date: Fri Feb 1 11:30:10 2008 Subject: Why orphaned? In-Reply-To: <734514.66296.qm@web51311.mail.re2.yahoo.com> References: <734514.66296.qm@web51311.mail.re2.yahoo.com> Message-ID: <47A34905.90601@spicycrypto.ca> Jon Hardcastle wrote: > 2) Where were you 2months ago when i needed advise > like that! Blissfully unaware of any of this, and thinking I'd never need to run another vss2svn conversion in my life. :) -Nathan > --- Nathan Kidd wrote: >> >> In the recent conversion I did I found it fairly >> easy to : >> >> 1. svnamin load, observe on which revision it fails >> 2. 'svndumptool split' [1] the failing revision out >> of the main dumpfile >> such that you get A.dump (revisions before bad rev), >> B.dump (the bad >> revision) and C.dump (revisions after bad rev). >> 3. Open B.dump in your favourite editor that won't >> mangle binary data >> (vi!) and fix it. (Does a parent directory need to >> be created? Is a >> rename wrong? Forcibly "un-orphan" a file by >> reconnecting its path to >> its true parent, etc.) The format is pretty easy to >> work with if you're >> careful -- just copy an entry similar to what you >> want and tweak. >> 4. svnadmin load A.dump, B.dump, C.dump >> 5. Goto 1, for any problem in C.dump. >> >> I found this much faster than trying to change >> something in the vss2svn >> process, and it guaranteed working results. >> >> -Nathan >> >> [1] http://svn.borg.ch/svndumptool/ From bryan.a.aldrich at gmail.com Fri Feb 1 11:31:28 2008 From: bryan.a.aldrich at gmail.com (Bryan Aldrich) Date: Fri Feb 1 11:31:34 2008 Subject: Why orphaned? In-Reply-To: References: <734514.66296.qm@web51311.mail.re2.yahoo.com> Message-ID: <91cfdb810802010831o3dfba160tbc29f237c3413215@mail.gmail.com> I used a slightly different method, though ours was not bad at all. I migrated the entire thing to SVN, pawed through the orphaned folder w/ a copy of the physical file list output from VSS. Then manually moved things back. I moved maybe 40 folders of data. Only one current VSS file was actually corrupt. Not enough for me to frett about. The ony big thing I noticed was, stable gave me a MUCH better conversion than nightly, Perhaps it was due to this corruption, but I wasn't sure. Bryan On Feb 1, 2008 11:28 AM, Larson, Aaron (SWCOE) wrote: > I agree with Jon. I spent weeks trying to get some of our repositories > converted, and eventually just gave up (way too much corruption). In > retrospect, we haven't used them all that much anyway, but when we do need > them it is a serious pain to get back to the data. > > I assume svndumptool refers to: > http://www.tonotono.net/ua/nph-.cgi/000000A/http/svn.borg.ch/svndumptool/ > > If so, then this little tidbit seems like a good addition to > http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration#Loadthedumpfileintotherepository > > What say the vss2svn wizards? > > -----Original Message----- > From: vss2svn-users-bounces@lists.pumacode.org [mailto: > vss2svn-users-bounces@lists.pumacode.org] On Behalf Of Jon Hardcastle > Sent: Friday, February 01, 2008 10:16 AM > To: Vss2Svn Users > Subject: Re: Why orphaned? > > 2 things.. > > 1) Show off! :) > > 2) Where were you 2months ago when i needed advise > like that! > > ;) > > --- Nathan Kidd wrote: > > > Jon Hardcastle wrote: > > > Just as a second to what this chap replied with - > > I > > > have just finished (well 2months ago) migrating > > > several repositories with chequered histories at > > > best.. and all quite large.. I got the best sucess > > > when i did the following. > > > > ... > > > Create your SVN repos.. and attempt an import. In > > my > > > experience it kept falling over on the import back > > in. > > > > > > My cut and burn solution to this was to delete > > delete > > > the file that caused the problem IN SOURCE SAFE. I > > > also found that if 1 file in a dir complained it > > was > > > likely several would - save yourself some time. if > > non > > > of the histories to these files are import purge > > the > > > directory containing them.. > > > > > > Repeat until you can migrate, and import without > > > error. > > > > In the recent conversion I did I found it fairly > > easy to : > > > > 1. svnamin load, observe on which revision it fails > > 2. 'svndumptool split' [1] the failing revision out > > of the main dumpfile > > such that you get A.dump (revisions before bad rev), > > B.dump (the bad > > revision) and C.dump (revisions after bad rev). > > 3. Open B.dump in your favourite editor that won't > > mangle binary data > > (vi!) and fix it. (Does a parent directory need to > > be created? Is a > > rename wrong? Forcibly "un-orphan" a file by > > reconnecting its path to > > its true parent, etc.) The format is pretty easy to > > work with if you're > > careful -- just copy an entry similar to what you > > want and tweak. > > 4. svnadmin load A.dump, B.dump, C.dump > > 5. Goto 1, for any problem in C.dump. > > > > I found this much faster than trying to change > > something in the vss2svn > > process, and it guaranteed working results. > > > > -Nathan > > > > [1] http://svn.borg.ch/svndumptool/ > > > > _______________________________________________ > > vss2svn-users mailing list > > Project homepage: > > http://www.pumacode.org/projects/vss2svn/ > > Subscribe/Unsubscribe/Admin: > > > > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > > Mailing list web interface (with searchable > > archives): > > > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > > > > > > ----------------------- > N: Jon Hardcastle > E: Jon@eHardcastle.com > 'The writing is on the wall...' > ----------------------- > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20080201/507ba208/attachment.html From nathan-svn at spicycrypto.ca Fri Feb 1 11:57:36 2008 From: nathan-svn at spicycrypto.ca (Nathan Kidd) Date: Fri Feb 1 11:58:01 2008 Subject: Why orphaned? In-Reply-To: References: Message-ID: <47A34F80.9070505@spicycrypto.ca> Larson, Aaron (SWCOE) wrote: > If so, then this little tidbit seems like a good addition to > http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration#Loadthedumpfileintotherepository Check it now. I had in the back of my mind to do this but thought the wiki had been made read-only because of spammers. However, it was writable, so I added a link to a new page: http://www.pumacode.org/projects/vss2svn/wiki/FixingTheDumpfile I added the general outline of my email there, but not specifics. If I get some time I'll try to see if I have a record of the specific svnadmin load errors and what I did to fix them. -Nathan From Stephen.Lee at hexagonmetrology.com Fri Feb 1 12:12:14 2008 From: Stephen.Lee at hexagonmetrology.com (Stephen Lee) Date: Fri Feb 1 12:12:41 2008 Subject: Why orphaned? In-Reply-To: <91cfdb810802010831o3dfba160tbc29f237c3413215@mail.gmail.com> References: <734514.66296.qm@web51311.mail.re2.yahoo.com> <91cfdb810802010831o3dfba160tbc29f237c3413215@mail.gmail.com> Message-ID: <47A352EE.4070904@hexagonmetrology.com> Bryan Aldrich wrote: > > The ony big thing I noticed was, stable gave me a MUCH better > conversion than nightly, Perhaps it was due to this corruption, but I > wasn't sure. Ummm.... there is no stable. There's a very out-of-date alpha which made a right pigs ear of it on the database I'm working with (tons of stuff in orphaned that shouldn't have been as it got rather confused, and a long list of files that needed some kind of manual fixup), a bunch of different "nightly" builds (of varying quality), and a repository from which you can roll your own at any given state of development. I believe the "alpha" one is fine if you never used any fancy facilities like sharing, pinning, archive/restore cycles, etc. and just had a straightforward create, check out, check in cycle. I'm not sure how many of the changes that I needed to do to get mine to work flawlessly last year actually made it into the repository, but it certainly is possible. -- Stephen Lee Software Engineer, Vision Group - Pro-Measure Leader Wilcox Associates Inc. (U.K.) From bryan.a.aldrich at gmail.com Fri Feb 1 12:28:04 2008 From: bryan.a.aldrich at gmail.com (Bryan Aldrich) Date: Fri Feb 1 12:28:13 2008 Subject: Why orphaned? In-Reply-To: <47A352EE.4070904@hexagonmetrology.com> References: <734514.66296.qm@web51311.mail.re2.yahoo.com> <91cfdb810802010831o3dfba160tbc29f237c3413215@mail.gmail.com> <47A352EE.4070904@hexagonmetrology.com> Message-ID: <91cfdb810802010928r590d5262m7aa74ed043d76a6b@mail.gmail.com> Sorry, I was referring to the alpha. The reason I didn't use the latest nightly was because it corrupted my db. the latest alpha just orphaned it. On Feb 1, 2008 12:12 PM, Stephen Lee wrote: > Bryan Aldrich wrote: > > > > The ony big thing I noticed was, stable gave me a MUCH better > > conversion than nightly, Perhaps it was due to this corruption, but I > > wasn't sure. > > Ummm.... there is no stable. > > There's a very out-of-date alpha which made a right pigs ear of it on > the database I'm working with (tons of stuff in orphaned that shouldn't > have been as it got rather confused, and a long list of files that > needed some kind of manual fixup), a bunch of different "nightly" builds > (of varying quality), and a repository from which you can roll your own > at any given state of development. > > I believe the "alpha" one is fine if you never used any fancy facilities > like sharing, pinning, archive/restore cycles, etc. and just had a > straightforward create, check out, check in cycle. > > I'm not sure how many of the changes that I needed to do to get mine to > work flawlessly last year actually made it into the repository, but it > certainly is possible. > > -- > Stephen Lee > Software Engineer, Vision Group - Pro-Measure Leader > Wilcox Associates Inc. (U.K.) > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pumacode.org/pipermail/vss2svn-users-lists.pumacode.org/attachments/20080201/df78baad/attachment.html From toby at etjohnson.us Fri Feb 1 19:14:23 2008 From: toby at etjohnson.us (Toby Johnson) Date: Fri Feb 1 19:14:25 2008 Subject: Undefined subroutine... In-Reply-To: <47A1F6C9.8020104@spicycrypto.ca> References: <3A2FF1DD2C821D4D999BD658754BAE038B5531@TUGOSP-BE03.thcg.net> <47A1F6C9.8020104@spicycrypto.ca> Message-ID: <47A3B5DF.6080805@etjohnson.us> Nathan Kidd wrote: > Ah, I didn't use autoprops. > > http://cpan.uwinnipeg.ca/htdocs/Text-Glob/README.pm.html says: > >> 0.08 Wednesday 2nd May, 2007 >> Expose glob_to_regex_string (Joshua Hoblitt) > > So if the exe is using e.g. 0.07 or earlier this error would make sense. Thanks Nathan, I did indeed have version 0.07 on the box I use to run the nightly build. I've upgraded to 0.08 so hopefully tomorrow's build fixes the issue. Pierre, let me know if you still have the problem after tomorrow's build, thanks. toby From toby at etjohnson.us Fri Feb 1 19:29:22 2008 From: toby at etjohnson.us (Toby Johnson) Date: Fri Feb 1 19:29:24 2008 Subject: Emptying a File's Content Requires "Text-content-length: 0" In-Reply-To: <47950F8C.3020100@spicycrypto.ca> References: <47950F8C.3020100@spicycrypto.ca> Message-ID: <47A3B962.1090806@etjohnson.us> Nathan Kidd wrote: > Sorry this is niether a patch (no time) nor a Ticket (no access, AFAIK). Unfortunately I had to remove anonymous ticket creation access due to spammers; keeping spam out of the wiki is enough of a chore! If you would like a login, let me know via private email what username you want (lowercase alphanum/underscore please) and I'll create one for you, which will give you full Trac permissions and svn commit access. toby From toby at etjohnson.us Fri Feb 1 19:36:59 2008 From: toby at etjohnson.us (Toby Johnson) Date: Fri Feb 1 19:37:01 2008 Subject: Emptying a File's Content Requires "Text-content-length: 0" In-Reply-To: <1905096263.20080122220539@dsn.ru> References: <1905096263.20080122220539@dsn.ru> Message-ID: <47A3BB2B.4070806@etjohnson.us> cd wrote: > Hi, > > I encountered problem with zero-length files, and solved it with the > following hack. Still, there are three incorrectly converted files > (not zero-length ones) in the head revision, but it is acceptable for > our project. > > Index: D:/projects/vss2svn_src/script/Vss2Svn/Dumpfile.pm > =================================================================== > --- D:/projects/vss2svn_src/script/Vss2Svn/Dumpfile.pm (revision 334) > +++ D:/projects/vss2svn_src/script/Vss2Svn/Dumpfile.pm (working copy) > @@ -859,13 +859,13 @@ > } else { > $textlen = length($text); > } > - return if ($textlen + $proplen == 0); > + return if ($textlen + $proplen == 0 && !defined $file); > > if ($proplen > 0) { > print $fh "Prop-content-length: $proplen\n"; > } > > - if ($textlen > 0) { > + if (defined $file || $textlen > 0) { > print $fh "Text-content-length: $textlen\n"; > print $fh "Text-content-md5: $digest\n" if $self->{do_md5}; > } > Thanks, I've committed this in r336. toby From toby at etjohnson.us Fri Feb 1 19:46:41 2008 From: toby at etjohnson.us (Toby Johnson) Date: Fri Feb 1 19:46:43 2008 Subject: Why orphaned? In-Reply-To: <47A34F80.9070505@spicycrypto.ca> References: <47A34F80.9070505@spicycrypto.ca> Message-ID: <47A3BD71.7020300@etjohnson.us> Nathan Kidd wrote: > Larson, Aaron (SWCOE) wrote: >> If so, then this little tidbit seems like a good addition to >> http://www.pumacode.org/projects/vss2svn/wiki/RunningTheMigration#Loadthedumpfileintotherepository >> > > Check it now. > > I had in the back of my mind to do this but thought the wiki had been > made read-only because of spammers. However, it was writable, so I > added a link to a new page: > http://www.pumacode.org/projects/vss2svn/wiki/FixingTheDumpfile This is great Nathan, thanks! That will hopefully help quite a few people out in fixing screwy dumpfiles. Unfortunately after witnessing many peoples' VSS databases over the past few years I've come to the conclusion that vss2svn could never be perfect because there will always be some unique corruption we've never seen. Too often getting the dumpfile is only half of the migration, with the other half being to fix the dumpfile so it can load! toby From pierre.roth at covidien.com Tue Feb 5 08:48:27 2008 From: pierre.roth at covidien.com (Roth, Pierre) Date: Tue Feb 5 08:48:39 2008 Subject: Undefined subroutine... In-Reply-To: <47A3B5DF.6080805@etjohnson.us> Message-ID: <3A2FF1DD2C821D4D999BD658754BAE038B5DA6@TUGOSP-BE03.thcg.net> Ok Tobby, everything's ok now. Used --auto_props without any problem. Thanks ! > -----Message d'origine----- > De : vss2svn-users-bounces@lists.pumacode.org > [mailto:vss2svn-users-bounces@lists.pumacode.org] De la part > de Toby Johnson > Envoy? : samedi 2 f?vrier 2008 01:14 > ? : Vss2Svn Users > Objet : Re: Undefined subroutine... > > Nathan Kidd wrote: > > Ah, I didn't use autoprops. > > > > http://cpan.uwinnipeg.ca/htdocs/Text-Glob/README.pm.html says: > > > >> 0.08 Wednesday 2nd May, 2007 > >> Expose glob_to_regex_string (Joshua Hoblitt) > > > > So if the exe is using e.g. 0.07 or earlier this error > would make sense. > > Thanks Nathan, I did indeed have version 0.07 on the box I > use to run the nightly build. I've upgraded to 0.08 so > hopefully tomorrow's build fixes the issue. > > Pierre, let me know if you still have the problem after > tomorrow's build, thanks. > > toby > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists > .pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss > 2svn.user > > From brucetwilson at gmail.com Wed Feb 6 14:45:51 2008 From: brucetwilson at gmail.com (Bruce Wilson) Date: Wed Feb 6 14:46:14 2008 Subject: Why orphaned? In-Reply-To: <47A352EE.4070904@hexagonmetrology.com> References: <734514.66296.qm@web51311.mail.re2.yahoo.com> <91cfdb810802010831o3dfba160tbc29f237c3413215@mail.gmail.com> <47A352EE.4070904@hexagonmetrology.com> Message-ID: <47AA0E6F.3070805@toomuchblue.com> Stephen Lee wrote: > I believe the "alpha" one is fine if you never used any fancy > facilities like sharing, pinning, archive/restore cycles, etc. and > just had a straightforward create, check out, check in cycle. We have never /intentionally/ used sharing, but SourceSafe's annoying UI has resulted in several dozen instances of [share], me: "crap!", [delete share]. Should I be concerned? From eugen_eugen at gmx.de Thu Feb 7 05:44:12 2008 From: eugen_eugen at gmx.de (Jewgenij Moldawski) Date: Thu Feb 7 05:44:21 2008 Subject: Why orphaned? In-Reply-To: <47A344A5.4030706@spicycrypto.ca> References: <856675.6291.qm@web51303.mail.re2.yahoo.com> <47A344A5.4030706@spicycrypto.ca> Message-ID: <20080207104412.283090@gmx.net> Hi Nathan! It's really great method with 'A', 'B', 'C' dumps! Thanks for the idea. Unfortunately was in my case the dumpfile at least once such corrupt, that 'svndumptool split' have been canceled with an exception (bad tag 'xyz'). And the entire dumpfile ist pretty big (~20GB) for vi :-( WbR Eugene > > In the recent conversion I did I found it fairly easy to : > > 1. svnamin load, observe on which revision it fails > 2. 'svndumptool split' [1] the failing revision out of the main dumpfile > such that you get A.dump (revisions before bad rev), B.dump (the bad > revision) and C.dump (revisions after bad rev). > 3. Open B.dump in your favourite editor that won't mangle binary data > (vi!) and fix it. (Does a parent directory need to be created? Is a > rename wrong? Forcibly "un-orphan" a file by reconnecting its path to > its true parent, etc.) The format is pretty easy to work with if you're > careful -- just copy an entry similar to what you want and tweak. > 4. svnadmin load A.dump, B.dump, C.dump > 5. Goto 1, for any problem in C.dump. > > I found this much faster than trying to change something in the vss2svn > process, and it guaranteed working results. > > -Nathan > > [1] http://svn.borg.ch/svndumptool/ > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From eugen_eugen at gmx.de Thu Feb 7 05:44:12 2008 From: eugen_eugen at gmx.de (Jewgenij Moldawski) Date: Thu Feb 7 05:44:22 2008 Subject: Why orphaned? In-Reply-To: <47A344A5.4030706@spicycrypto.ca> References: <856675.6291.qm@web51303.mail.re2.yahoo.com> <47A344A5.4030706@spicycrypto.ca> Message-ID: <20080207104412.283090@gmx.net> Hi Nathan! It's really great method with 'A', 'B', 'C' dumps! Thanks for the idea. Unfortunately was in my case the dumpfile at least once such corrupt, that 'svndumptool split' have been canceled with an exception (bad tag 'xyz'). And the entire dumpfile ist pretty big (~20GB) for vi :-( WbR Eugene > > In the recent conversion I did I found it fairly easy to : > > 1. svnamin load, observe on which revision it fails > 2. 'svndumptool split' [1] the failing revision out of the main dumpfile > such that you get A.dump (revisions before bad rev), B.dump (the bad > revision) and C.dump (revisions after bad rev). > 3. Open B.dump in your favourite editor that won't mangle binary data > (vi!) and fix it. (Does a parent directory need to be created? Is a > rename wrong? Forcibly "un-orphan" a file by reconnecting its path to > its true parent, etc.) The format is pretty easy to work with if you're > careful -- just copy an entry similar to what you want and tweak. > 4. svnadmin load A.dump, B.dump, C.dump > 5. Goto 1, for any problem in C.dump. > > I found this much faster than trying to change something in the vss2svn > process, and it guaranteed working results. > > -Nathan > > [1] http://svn.borg.ch/svndumptool/ > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From nathan-svn at spicycrypto.ca Thu Feb 7 11:30:16 2008 From: nathan-svn at spicycrypto.ca (Nathan Kidd) Date: Thu Feb 7 11:30:33 2008 Subject: Why orphaned? In-Reply-To: <20080207104412.283090@gmx.net> References: <856675.6291.qm@web51303.mail.re2.yahoo.com> <47A344A5.4030706@spicycrypto.ca> <20080207104412.283090@gmx.net> Message-ID: <47AB3218.3020805@spicycrypto.ca> Jewgenij Moldawski wrote: > It's really great method with 'A', 'B', 'C' dumps! Thanks for the > idea. Unfortunately was in my case the dumpfile at least once such > corrupt, that 'svndumptool split' have been canceled with an > exception (bad tag 'xyz'). And the entire dumpfile ist pretty big > (~20GB) for vi :-( I had exactly the same problem. I used a combination similar to: tail '-n+X | head -n1000 | grep ^Revision-number (syntax is probably not 100%) incrementing X till I found the revision svndumptool was bombing on, and then to examine the surrounding dumpfile. I documented the result here: http://www.pumacode.org/projects/vss2svn/wiki/FixingTheDumpfile#DumpfileIsCorrupt (Quick version: run on linux, not windows) -Nathan