Hi Werner,
There are some zero length file checkins in my database probably done to avoid file deletions which VSS does not really handle very well. These are omitted from the output of dumpfile.pm. The patch fixes this.
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.
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.
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.
With these changes the number of defects got down from 1% to 0.03%. Therefore I can recommend the widetime branch as an improvement. There are still some issues left. I've identified some cases:
Good to hear.
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'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?
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
Best regards Dirk _______________________________________________ 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
