Sorry, didn't reply to all :( ---------- Forwarded message ---------- From: Kirit Sælensminde <[EMAIL PROTECTED]> Date: 01-Dec-2006 12:24 Subject: Re: Another migration tool To: Dirk <[EMAIL PROTECTED]>
On 30/11/06, Dirk <[EMAIL PROTECTED]> wrote:
Hi Kirit, thanks for the article. Can you enlighten us, how you actually do the conversion. Is it * vss commandline based * vss ISAPI based * or direct database decoding?
I use both SS.EXE and SVN.EXE as command line clients. The tool is able to cache the SourceSafe history which significantly speeds up the start up. I didn't see any benefit of trying to learn the Subversion dump file format nor the SourceSafe database format. Is there more information available in the actual SourceSafe database than is exposed through SS.EXE? If so then it may be that replacing SS.EXE with a database reader could simplify some of the heuristics used for ordering etc. in the tool. It would only be worthwhile though if my tool has better modeling of how the SourceSafe repository changed over time than the existing vss2svn tool does. How is this handled?
Since we worked also very hard on getting things "right" during the conversion, there are a few concepts that are not easily mapped between the two tools. Esp. the archive and restore cycles are the most problematic one. Have you solved this problem domain and how did you solve it?
I'm not 100% sure what you mean here. SourceSafe has no concept of transactions - each file submission is handled seperately, so the migration doesn't attempt to guess where transactions might be valid. In practice each file version that is sent to Subversion is a seperate transaction (revision number). My tool is able to correctly handle all of the cases where a SourceSafe repository was restored into a different one that I had - both in the test repository I built and our main live one. Better handling of shared files is the main thing that the tool is able to handle. If you have a simple situation where a file is developed and then shared to each location it is used then this tool will handle that much better than other tools I've seen, i.e. it will not put multiple versions of that file into Subversion until after the share occurs. What does vss2svn do in this situation? I've been thinking of putting together a single page with all of the tools I can find with a short description of what they actually import in terms of the SourceSafe history into Subversion. Concerning the suggested benefit of sharing, I have to warn you. NEVER
EVER rename a shared file. This will rename the file throughout all the shares :-(.
I can imagine that could get messy :-) We used it in much the same way as a file level svn:export though so if we renamed a shared file then that was the behaviour we wanted. Can't remember that we ever did it though. K -- http://www.kirit.com/ -- http://www.kirit.com/
_______________________________________________ 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
