On 10-02-17 08:21 AM, Anu Menon wrote:
If anyone else has any other suggestions, do let me know. I'm also curious if there are some general rules that prevent files from getting migrated - i.e. labelling or 'spaces' in project/file names etc..
Since everyone's form of VSS corruption is different, the sad VSS-reality is you can end up in a situation like yours. Of course you could analyze the conversion process in depth, do a lot of stepping in the perl script and probably add in enough hacks particular to your repo to get a better conversion, it's just a matter of how much time you want to invest.
The only word of advice I have is: if you're converting a source code database don't underestimate the value of having full "annotate" history in svn (or whatever scm you end up with in the end).
When we converted from vss the vss repo history converted fine, but we failed to take into account that the vss repo itself had been made by a HEAD checkout from another vss repo at one point. On a semi-regular basis I'm trying to understand the full evolution of a piece of code (Tortoise Blame's "blame previous revision" rocks) but when I hit that "imported from other vss repository" wall I'm forced to open ssexp and go stabbing in the dark in vss history; lots of time wasted and pain.
(Oh, I do have another word of advice: use git) :) -Nathan _______________________________________________ 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
