Jonathan Perret wrote:
The only other steps that are Windows-specific are those that use ss.exe
(to clean up the VSS DB) and analyze.exe (to fix DB errors). One can
certainly do without these but they do help. In particular it sounds
better to fix errors with analyze.exe rather than have vss2svn twist
around to understand an inconsistent DB. For example in my DB
it found (and fixed) a case of
"There is a version sequence mismatch in the log file for
'somefile.txt' (keaaaaaa)."
which may or may not be related to the recent "Invalid change ordering"
thread...
Also, I don't really see the problem with requiring VSS. After all that
DB you want to migrate is being used so you're bound to have a copy
or two of VSS lying around :) But perhaps you have another
scenario in mind ?
I completely agree that if someone has analyze.exe then it is indeed
best to use that tool to fix problems beforehand. But believe it or not
we've had numerous inquiries in the past from people who don't have VSS
installed anymore and want to convert their repo (especially with the
original version of the script which required ss.exe to run).
Don't get me wrong, I certainly appreciate your putting all this down
into a reproducible recipe and I think that others can definitely
benefit from having this information. I think your scenario probably
matches that of at least 90% of other users.
toby
_______________________________________________
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
