--On Monday, September 18, 2006 8:51 PM +0200 Dirk <[EMAIL PROTECTED]> wrote:
This is hard to believe, that this is a real scenario. Not similarity in the bit pattern, and I don't expect somebody waited for 54 hours for the operation to complete. This is also more than the summer / winter time shift, and I would also think, that nobody adjusted the timestamp on the server during that action.
My theory now is that the file server was offline or inaccessible for a weekend and the VSS client stalled in the middle waiting for it to come back.
Have you looked in the "time flow" of the parent and child item? Are they intact by them self? What does vss reports in this case for the time stamp for both histories, parent and client?
Everything looks correctly ordered.
Do you know which one is the correct time?
No.
Did you run analyze at some point of time and one of the records is actually broken?
The DB gets taken offline every Wednesday evening for "maintenance" (which I believe is at least an analyze pass) and my working snapshot is from such maintenance.
Today's result from that snapshot now has no mismatches in the main trunk, and I'm going to run the conversion again against an rsync snapshot of today's DB.
The main changes from my last work were to increase the time tolerance to 72 hours and add the handler entry for RestoredProject. I'll check this into a branch for your inspection.
_______________________________________________ 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
