Following up from my previous post, I think I've discovered what was
going wrong. It seems that either there is a problem with my server's
setup, or that there is some issue between Subversion/PySvn and Apache
that causes the performance degradation. If I run the script using
svnserve as the host, then everything remains at full speed. Everything
is now exported happily from VSS and into Subversion :)
For anyone who is interested in playing with the script I wrote, I've
uploaded it to my personal web server at http://jasonfield.com/ - follow
the freebies link.
Andrew Thompson wrote:
> Jason Field wrote:
>> I've recently been trying to export a VSS repository to Subversion using
>> the PySvn bindings.
> pysvn looks like a Python library for SVN. Are you saying that you're
> using a python script that references pysvn to to export your VSS
> data? (huh?)
> Or are you're just using pysvn workbench as a user frontend to SVN?
>> Everything seems to be working well, except for the
>> massive decrease in performance that occurs if I set the script to
>> change the date revision property of checkins. Does Subversion require
>> that ascending revisions have ascending datestamps?
> Are you saying that if you make two repositories, one including the
> old dates and one excluding the old dates, the performance of the two
> repositories are different? I would consider that very curious...
> Wait... Does your "massive decrease in performance" occur during the
> post-conversion usage of the SVN repository, or during the export of
> data from VSS to SVN. If it's only during the export, I would consider
> that a cost of doing business with Microsoft. It *should not* affect
> everyday usage.
> > I assumed that the
>> date property was entirely independant of the revision number but
>> perhaps I'm wrong! The performance drop off makes the repository
>> unusable unfortunately, and yet it would be very handy to maintain the
>> entire VSS structure including dates. Any ideas appreciated!
> See recent threads on date ranges over the last few days for the
> ramifications. (I can't recall if it was on users@ or dev@.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu May 26 13:44:04 2005