>>>>> "D" == Dirk <Dirk> writes: Dirk, first let me thank you profusely for your efforts on this. You have been unbelievably helpful.
AL> ssphys: unknwon record type "œ7" detected (offset 0x8f7) TASK: D> This really sounds like a broken phyiscal file. Can you run with D> --debug and --verbose to see which file is the borken one? Then try D> to move the phyiscal file out of your data folder and rerun D> again. But I expect, that this is not the root of the problems. I will do. A suggestion for ssphys though would be to output the file name :-) AL> ERROR -- Attempt to commit unknown item 'UBSAAAAA': at vss2svn.pl line 745 D> This sounds like a broken timeline. One commit record has a time D> stamp earlier than the add/create time. So we will see a commit D> before we have added the file to the database. The current vss2svn D> converter does not perform a check the linearity of the D> timestamps. This would be difficult anyway, but at least we could D> check for linearity and report any possible errors. Can you try to D> run "ssphys info UBSAAAAA" and check your timestamps on each D> version? I'm not exactly sure what to look for here, but I did: ssphys info UBSAAAAA | grep Date > orig bash-3.00$ sort < orig > sorted bash-3.00$ diff orig sorted orig and sorted are the same. I presume this means the dates are not an issue. I sent you the entire ssphys output in a separate email. AL> ERROR -- Attempt to share unknown item 'KROBAAAA': at vss2svn.pl line 745 D> I expect the same here. We have some item related activities before D> we have added the file. Actually, the file KR0BAAAA does not appear in the database. It wasn't deleted as part of the analyze runs I did either, although it might have disappeared from a previous analyze. D> By the way, this can happen very easily if you had a one computer D> in the network with a wrong time. Every client will enter it's own D> timestamp to the version records. There is no idea about a global D> time. We had part of our team in the USA, part in India. Words can't express my disgust when I found out the labeling was based on "local" timestamps. However, if I've interpreted the data above properly, the cause of the problem would seem to be more subtle. BTW, if you'd like I can send you the entire vss2svn output log, its about 90kb. AL> Use of uninitialized value in concatenation (.) or string at /PerlApp/Vss2Svn/ActionHandler.pm line 264. AL> Use of uninitialized value in join or string at vss2svn.pl line 789. AL> Use of uninitialized value in concatenation (.) or string at /PerlApp/Vss2Svn/ActionHandler.pm line 640. D> Ok, this is more complicated, but I expect also, that this is due to the D> timestamps problem. Ok, but I guess I have to find what file is causing the problem first. D> As a next step I would suggest to add a new basic time stamp D> check. This check could simply check for the linearity of the D> activities on each physical file. If one time stamp is out of D> order, we could move it to the timestamp between the two D> actions. Again, this is problematic, but would help to get the D> archive converted. It will however mess up your labels. Perhaps the labels are wrong now, and this would fix it :-) D> Can you do Perl programming? I will, of course, not admit to being able to program in perl in a public forum. But if you promise not to tell, then I'll say I'm conversant. I do however doubt I will ever understand array vs scalar context. D> The best place to do this is in the GetVssItemVersions function. I D> will give it a quick try... If I could get a source installation running, then I would be much more help. Sadly the last time I tried this I get hung up on a perl dependency that I couldn't unravel. Knowing a bit better what environment works (cygwin perl, vs activestate, vs ???, etc.) might get me past that hurdle. I could also try this on my personal Linux box. _______________________________________________ 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
