I do know, however (as you probably do as well), that Visual SourceSafe can
easily be affected if the date / time of the client PCs is not correct at
the time of a particular action. So, if they made changes to the DB and the
client PC had an incorrect date, then you've effectively made a mess of your
archive. For a DB that's nearly 10 years old, it's likely that at least
once or twice the date was wrong on a system. So there's really no
intentional "strange concepts" used in the archive maintenance. It's
probably just an instance of me inheriting a messy DB. Sadly enough, this
is a documented problem with VSS.
This is true in the fact, that you can mess up the time sequence, but
not in the way of your archive. VSS is completely server less, so the
only timestamp in question is the timestamp of the client accessing the
shared files. If a file is create with the wrong timestamp, it is
CREATED with the wrong time stamp and it is ADDED with the wrong
timestamp. So actually the internal bookeeping of the database is
correct, only the linearity is wrong.
Your time mess is completely different. Files are added to project
before they are created and there is no logic behind this shift. It is
not a timezone problem nor a potential broken single bit. There is a
pattern behind the problem, but I can't see the logic.
The only idea I have to force this problem is if your local time while
comitting. But this is nearly impossible.
Another idea would be, that you mixed to archives, but also nearly
impossible.
I ran the VSS 2005 analyze utility against the DB and it found a large
number of errors that the 6.0 analyze utility did not. However, when I try
to do the load of the dump file into Subversion, it's failing at the same
point.
The only thing I can think of doing off the top of my head is for me to hack
the conversion script to verify time linearity and if errors are found, to
replace the out-of-sequence timestamp with a normalized stamp. This will
give me some incorrect timestamps, but should be sufficient to get the data
to load into Subversion. Any thoughts or comments about this approach?
Yes, we are looking into a similar long term solution, but we also know
that sometimes the organizational data is broken, so that this also
wouldn't help to completely eliminate the problem. On the other hand we
can not fix broken archvies during the conversion. If information is
lost, it is lost. We can only help converting them, so that the end user
can fix the errors in subversion.
I will have a look into the time shift agin and see, whether I can find
some logic. I also checked for a Y2K problem, but the greatest mess
happend 1996/1997.
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
