> > If I read this correct, you mean your development team used a zero > content checkin workaround in order to prevent file deletions. Because, > there is no code in vss2svn that will rewrite deletions into zero content. > Well I can only guess why someone would want to check in a zero length file. But this is what I found in the database and vss2svn just omitted these checkins and the file was fully restored after the conversion.
> > The change in line 769 just moves the timestamps into my timezone > > (UTC+2h). This would be a candidate for a command line parameter. > > In C/C++ there is a corresponding "localtime" function that will return > the time in the correct timezone. Isn't there an equivalent function for > perl? But anyway, we could also change it into a command line parameter. > Yes but VSS timestamps are already local time. And applying localtime to a local time would shift the time even farther away from UTC. What would be needed here is a function that guesses the correct timezone and daylight savings active at that time and reverse it. > > The FixAddParentTimestamp corrects the problem that some parents are > > created after their childs which causes the svn import to fail. > > This is a workaround for the archive or delete szenario, where the real > parents of the item does not exist anymore. I'm not sure, whether this > is the correct solution and I don't want to be picky here. The old code > should have detected this situation in the SanityChecker and should have > moved all these problematic files into the orphaned folder, until the > creation of their new parent. I think we should work on this side and > improve the logic, to fix the remaining issues. I expect also > conflicting szenarios that are very problematic to solve. for example > think of two projects with the same name. > There was at least one action for the child that was related to a particular existing parent before its creation otherwise the svn import would not have failed. Actually without the widetime patches these files were orphaned but then missing in the parent and the import succeeded. > > Files that have beed deleted, recovered then shared and pinned back > > past the point where they had been recovered. They have a newer > > version than they are pinned to. > > is the pin point also before the point where the item has been deleted, > or is it in between? See also your last observation. > I believe these files had no version between the deletion and the recovery to which they could have been pinned. I will check that again. > > I've found one file that has been branched first then shared. No idea > > how this could happen. > > Why is this problematic? E.g. you can branch baaaaaaa to caaaaaaa, and > later share baaaaaaa to some other place. also you can share the > branched item caaaaaaa to any other place. Or did I misunderstood you? > I think the branch was the very first action before any share. Maybe I am misinterpreting this. Please see the attachment. > > And one file that was recovered has seen a commit while it was deleted. > > Yes this can happen via shares. If one share of a shared file is > deleted, the still existing share will also update the deleted share > during commits (the physical file of the two share is identical). If you > recover, the item will be recovered to the latests state, regardless of > the state prior to the delete. > > In svn each item is seperate. Commiting to a shared item will result in > a commit to all shares. Since one of the item is deleted, we can not > commit to this deleted item. Recovering, will recover to the state prior > of the delete. The only way is to not really delete the items, but to > move them into the _Attic. There they can take place in commits and if > we recover, we move them out of the _Attic. > > Another alternative would be to not recover the file, but to copy From > one of the vivid shares. > > A third alternative would be to generate 2 subversion actions: 1 > recover, and one commit to the last state > The first alternative would be best if this is only done for files that had a commit during the deletion. The last alternative would produce a commit that no one knows where it was coming from. The second is ok when there is a comment stateing that this was meant to be a recover.
datacache.PhysicalAction.tmp.txt:196837 JQLAAAAA 1 \N ADD BLACKBOX.H 2 903622448 sf 0 \N 1 AAAAALQJ 0 datacache.PhysicalAction.tmp.txt:233870 JQLAAAAA \N LPLAAAAA ADD BLACKBOX.H 2 903622448 sf 0 \N 1 AAAAALQJ 1 datacache.PhysicalAction.tmp.txt:167391 JBPAAAAA \N IBPAAAAA ADD BLACKBOX.H 2 922204213 sf 0 \N 1 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:187187 JBPAAAAA 1 \N ADD BLACKBOX.H 2 922204213 sf 0 \N 1 AAAAAPBJ 0 datacache.PhysicalAction.tmp.txt:189214 JEJBAAAA 2 \N BRANCH BLACKBOX.H 2 950785128 sf 0 JBPAAAAA 3 AAAABJEJ 0 datacache.PhysicalAction.tmp.txt:494972 JBPAAAAA \N YRAAAAAA SHARE BLACKBOX.H 2 950785616 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:494973 JEJBAAAA \N YRAAAAAA BRANCH BLACKBOX.H 2 950785641 sf 0 JBPAAAAA 3 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:167588 JBPAAAAA \N IBPAAAAA DELETE BLACKBOX.H 2 951472781 sf 0 \N 5 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:167590 JBPAAAAA \N IBPAAAAA RECOVER BLACKBOX.H 2 951697254 sf 0 \N 5 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:34604 BPSBAAAA 5 \N BRANCH BLACKBOX.H 2 956500011 sf 0 JEJBAAAA 3 AAAABSPB 0 datacache.PhysicalAction.tmp.txt:294633 BPSBAAAA \N OOSBAAAA BRANCH BLACKBOX.H 2 956500011 sf 0 JEJBAAAA 3 AAAABSPB 1 datacache.PhysicalAction.tmp.txt:294632 JEJBAAAA 4 OOSBAAAA SHARE BLACKBOX.H 2 956500011 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:1910 BCUBAAAA \N ACUBAAAA BRANCH BLACKBOX.H 2 956500255 sf 0 JBPAAAAA 3 AAAABUCB 1 datacache.PhysicalAction.tmp.txt:24887 BCUBAAAA 2 \N BRANCH BLACKBOX.H 2 956500255 sf 0 JBPAAAAA 3 AAAABUCB 0 datacache.PhysicalAction.tmp.txt:1909 JBPAAAAA 1 ACUBAAAA SHARE BLACKBOX.H 2 956500255 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:169652 IEFCAAAA 5 \N BRANCH BLACKBOX.H 2 959341441 sf 0 JEJBAAAA 3 AAAACFEI 0 datacache.PhysicalAction.tmp.txt:421789 IEFCAAAA \N VDFCAAAA BRANCH BLACKBOX.H 2 959341441 sf 0 JEJBAAAA 3 AAAACFEI 1 datacache.PhysicalAction.tmp.txt:421788 JEJBAAAA 4 VDFCAAAA SHARE BLACKBOX.H 2 959341441 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:159931 IRGCAAAA \N HRGCAAAA BRANCH BLACKBOX.H 2 959341750 sf 0 JBPAAAAA 3 AAAACGRI 1 datacache.PhysicalAction.tmp.txt:179740 IRGCAAAA 2 \N BRANCH BLACKBOX.H 2 959341750 sf 0 JBPAAAAA 3 AAAACGRI 0 datacache.PhysicalAction.tmp.txt:159930 JBPAAAAA 1 HRGCAAAA SHARE BLACKBOX.H 2 959341750 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:323496 JEJBAAAA 4 PYADAAAA SHARE BLACKBOX.H 2 974293175 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:262249 JBPAAAAA 1 NBBDAAAA SHARE BLACKBOX.H 2 974293471 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:214687 JEJBAAAA 4 KQFDAAAA SHARE BLACKBOX.H 2 991407248 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:276744 JBPAAAAA 2 NSFDAAAA SHARE BLACKBOX.H 2 991407366 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:59818 JEJBAAAA 4 CUGDAAAA SHARE BLACKBOX.H 2 992356087 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:122294 JBPAAAAA 2 FWGDAAAA SHARE BLACKBOX.H 2 992356236 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:146633 JEJBAAAA 4 HBJDAAAA SHARE BLACKBOX.H 2 1006246226 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:264885 JBPAAAAA 2 NDJDAAAA SHARE BLACKBOX.H 2 1006246385 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:5685 JEJBAAAA 4 AGLDAAAA SHARE BLACKBOX.H 2 1013697881 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:132682 JBPAAAAA 2 GILDAAAA SHARE BLACKBOX.H 2 1013697943 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:371775 JEJBAAAA 4 SPMDAAAA SHARE BLACKBOX.H 2 1015518179 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:495812 JBPAAAAA 2 YRMDAAAA SHARE BLACKBOX.H 2 1015518248 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:487309 JEJBAAAA \N YHODAAAA SHARE BLACKBOX.H 2 1018634358 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:111946 JBPAAAAA \N FKODAAAA SHARE BLACKBOX.H 2 1018634454 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:54254 JEJBAAAA 4 CNUDAAAA SHARE BLACKBOX.H 2 1032262617 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:178297 JBPAAAAA 2 IPUDAAAA SHARE BLACKBOX.H 2 1032262684 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:265309 JEJBAAAA 4 NDWDAAAA SHARE BLACKBOX.H 2 1034872830 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:423839 JBPAAAAA 2 VFWDAAAA SHARE BLACKBOX.H 2 1034873217 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:230180 JEJBAAAA 4 LKDEAAAA SHARE BLACKBOX.H 2 1077268363 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:351784 JBPAAAAA 2 RNDEAAAA SHARE BLACKBOX.H 2 1077268414 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:431351 JEJBAAAA 4 VPMEAAAA SHARE BLACKBOX.H 2 1113844472 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:217033 JBPAAAAA 2 KSMEAAAA SHARE BLACKBOX.H 2 1113844514 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:8677 JEJBAAAA 4 AJREAAAA SHARE BLACKBOX.H 2 1126801169 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:312885 JBPAAAAA 2 PLREAAAA SHARE BLACKBOX.H 2 1126801360 sf 0 \N 2 AAAAAPBJ 1 datacache.PhysicalAction.tmp.txt:291247 JEJBAAAA 4 OKZEAAAA SHARE BLACKBOX.H 2 1148288490 sf 0 \N 2 AAAABJEJ 1 datacache.PhysicalAction.tmp.txt:315499 JBPAAAAA 2 POZEAAAA SHARE BLACKBOX.H 2 1148288552 sf 0 \N 2 AAAAAPBJ 1
_______________________________________________ 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
