I'm really not sure how much a loss in older data would affect us. My suspicion is that the loss would be relatively unimportant. I know personally I've never had to reference any data older than approximately 2 years past (unless a particular file hadn't been modified in less than 2 years, at which point, I'd simply need the latest copy). My current thinking is that in my personal situation, if I could get the past couple years worth of data into the database I'd be fine. If I need to reference older files, then I could simply fire up SourceSafe.
The only thing that I'd really like to retain are the labels, which is why it would be great to get the ssphys.exe version of vss2svn working. I was looking at the ss.exe-based version however, and I could easily modify that script to mimic the current status of the archive and generate the labels. On a quick side topic regarding the labels... our archive has labels that contain the character '/' and when the label gets committed to the Subversion repository it ends up creating labels that have subdirectories. So that might be a potential issue to fix (with the obvious solution to replace the '/' with another valid character). Just a thought. :-) Tbanks again for all of your assistance with this. I really appreciate it. jward. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Sent: Tuesday, June 06, 2006 4:03 AM To: Vss2Svn Users Subject: Re: pin_handler: another file history issue > 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 _______________________________________________ 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
