Check out
http://www.laine.org/cvs/vss2cvs/vss2cvs.pl
That perl script may give you a good head start. It migrates Visual
SourceSafe to CVS. That may be a better match to what you're trying to
do than cvs2svn is. (At least in the approach, though not in the
implementation language!)
Steve Dwire, Sr. Technical Architect, (630) 250-3045 x104
Park City Solutions - (iServices)
500 Park Blvd., Suite 295-C, Itasca, IL 60143
CONFIDENTIALITY NOTICE
This message and any included attachments are from Park City Solutions
Inc. and are intended only for the entity to which it is addressed. The
contained information is confidential and privileged material. If you
are not the intended recipient, you are hereby notified that any use,
dissemination, or copying of this communication is strictly prohibited
and may be unlawful. If you have received this communication in error
please notify the sender of the delivery error by e-mail or call Park
City Solutions Inc. corporate offices at (435) 654-0621
-----Original Message-----
From: Jens B. Jorgensen [mailto:jens.jorgensen@tallan.com]
Sent: Wednesday, July 16, 2003 11:41 AM
To: dev@subversion.tigris.org
Subject: vss2svn.py: underway and looking for
suggestions/collaboration/...
Ok, so I've gotten started writing vss2svn.py, a utility to do a
one-time conversion from Visual SourceSafe to svn. Naturally this is a
personal itch I'm scratching since I'd like to get my current client to
switch over. I've been going over cvs2svn.py and I'm following the same
basic approach: I'm using the vss automation interface to iterate over
the repository tree and generating a flat file with timestamp,
author/comment hash, rev #, and path and then sorting that file and
processing it line-by-line to generate a dump file. At least at this
stage (because it suits my own needs) I'm completely ignoring the
"branch" and "share" "features" of VSS since we have not (and would
not!) ever use them. All we have then are adds, commits, renaming, and
deletions (haven't decided what to do about labeling but since we don't
use it in the obvious tag-like way I'm thinking of taking the cowards
way out on that one). My first thought was naturally to re-use as much
of cvs2svn.py as possible. On the other hand cvs2svn.py does a lot of
things that are necessary to handle cvs but are not needed/necessary for
the simple cases I'm dealing with and disentangling what vss2svn.py
needs from cvs2svn.py (especially when it is under such active
development, cvs2svn.py has a median time between checkins of 23.94
hours!) could prove to be a lot of work and perhaps more than I can
devote.
So I guess what I'm looking for from the community is perhaps guidance
(goadance?). It seems The Right Thing To Do is to least abstract out
class Dumper from cvs2svn.py (kfogel: care to jump in and comment?) and
put it in a separate module that both cvs2svn.py and vss2svn.py could
use. Or, maybe since the overall structure is very nice and probably
reusable perhaps go further and abstract out the whole structure of the
process and let the cvs-specific and vss-specific stuff be a sub-class
of some generalized class. There seems to be enough in common between
these two (the kind off VSS functionality I'm doing seems like a strict
subset of the cvs functionality) that there certainly seems to be
opportunity to leverage the work done in a more productive and valuable
way than just the classic reuse form (copy-n-paste).
Another thing I guess I'm wondering is if anyone else out there has
already written what I'm writting and I'm wasting my time. Alternatively
perhaps there are those out there that would like to use such a beast
and would have an immediate need. We could join forces and if nothing
else perhaps others could use and test the stuff I'm writing.
Anyone care to comment?
--
Jens B. Jorgensen
jens.jorgensen@tallan.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 27 15:41:58 2003