> >316 files into a VSS project of ~1100 files and it's output over 630,000
> >temp files so far. It has slowed down to about 20-25 files per hour.
> Well, I'm pretty much at a loss then. I suppose I could include an
> option to delay extracting and saving the comments until the moment
> they're needed, which of course would slow down the whole process quite
> a bit also.
It's still going. Now at ~1.4 million files.
> Or I could split the history-recreation phase into two phases (for a
> total of, let's see, four phases I think). At first it would migrate the
> entire history without any comments at all, then go back and attach the
> comments to the proper revisions, extracting them from VSS one at a time.
> Of course, both of these approaches may very well end up taking just as
> long as it does now, but at least it should be much more scalable.
> Unfortunately, since comments are used to determine if multiple VSS
> commits should be part of the same transaction, delaying the processing
> of comments would disable this functionality. I could, in that case, use
> just author and date when grouping transactions, maybe checking to
> ensure multiple commits were within, say, 10 minutes of each other (VSS
> can be pretty slow when commiting lots of changes at once).
The matching of comments would not work for us since a lot of our developers
have a habit of not entering any comments.
I may end up just doing an import of our source tree into SVN at the time we
change over. Keep the SourceSafe database available for a while for
historical purposes. Start fresh in SVN.
> Now that I think about it, splitting up VSS projects to migrate them
> individually isn't a good solution either, especially if you're
> migrating dates as well. I believe I've read on this list that all
> revisions must be chronological according to svn:date.
Splitting them worked for me because I was planning to migrate each
SourceSafe project into a separate SVN repository anyway.
> As a side note, I have decided to open up a separate project for this
> script on tigris.org; more on that once it's approved. I still don't
> plan on supporting this very long-term, but at least this way others
> could more easily make changes, and we can also offload this discussion
This is a good thing. It keeps everything at the tigris site so it's easy
to find. The script you have made does work well (so far), but it probably
better suited to small SourceSafe databases.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 27 08:30:21 2004