On 01/12/06, Toby Johnson <[EMAIL PROTECTED]> wrote:
> > 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). Dirk was referring here to the act of using the VSS "Archive" command followed by a later "Restore"; as I mentioned above, this really screws with the timestamps. However, since you mention transactions, I should point out that we try to deduce atomic transactions in VSS by assuming that if consecutive VSS commits have the same author and comment, they are part of the same logical transaction, and are recreated in Subversion that way. We keep track of any files that are modified in a given transaction, and "commit" that transaction whenever the same file is about to be modified twice (there are also other cases where we always immediately commit, such as after a rename).
When there is a project (directory structure) restored from someplace else then of course you have versions of the files that occur before the holding directory exists. I guess this is the problem that you're refering to. What I do is to create a directory, _vss_deleted, into which I place these file versions (building the restored directory tree in there). Once it gets to the point of time that the restore is performed then a svn move command puts that directory tree in the correct location. The same location is used for files where versions are found, but we have lost all information for where they where (i.e. they've been moved, branched or otherwise buggered about with and the trail has gone cold). Once we get an event (normally a version, but could be a share) in a known directory then the file is moved from this holding directory and everything proceeds normally - note that there must be an event that does this as we only see versions for files that are extant in a directory when the tool runs. The last thing the tool does is to delete this holding directory which should be then be empty. It's not a very elegant solution, but it does work. Generally I do a commit after each event is replayed - less brain ache that way. I believe we are doing the same thing here; specifically, when an item
was shared in VSS we treat that as a Subversion "cheap copy". We keep track of all shares during the migration, and after a share occurs, then any commits which are made to any of the various logical locations which point to the same physical file are propagated to each file in Subversion. So when foo.txt is shared to bar.txt, that is treated as an "svn copy" action. Then if a commit is made to foo.txt, that change will be made to both foo.txt and bar.txt in the same transaction.
You're a little more sophisticated here. My sorting heuristics mean that I can't reliably tell if any two versions I see are actually the same commit or not. Better information would give better ordering and should show this up. In my tool versions for VSS shared files are done as seperate transactions. One final question if I may - do you run svn commands using the command line client, the API or do you build a dump file? Unfortunately, as you can imagine, all of this is rather complex, and
the learning curve for just getting familiar with the code is very steep. Couple that with the fact that most people will only use such a tool once, and you can see that it very difficult to continue innovation of such a project! I doubt I will ever need to perform another VSS migration (I hope to live the rest of my life without ever actually using the tool for real source control again :) so the "scratch your itch" motivation of most open source projects quickly diminishes.
Indeed. It is an interesting intellectual challange I suppose, but that isn't really enough to build a very sophisticated tool. Thanks for the detailed response though, very interesting :-) K -- 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
