OT? Subversion anyone?

The GCC project uses SVN, and performance is comparable to anything else I've used. Sounds like your installation or software is to blame.

I used it at my PPOE, having moved my new projects from VSS (which had been inflicted upon us by a long-departed director) to CVS, and then we decided to move up to Subversion because a lot of collaborative work we were doing needed it. I'd take CVS or SVN over VSS any day. I trust them.

pete

The linux versions work fine, but I have problems with a windows version @ work. It frequently gives transient 'access denied' errors and can't make it through uploading a directory with 200 files without crapping out. Try to redo the operation and it'll crap out on the first file that was already checked in -- terribly unrobust for recovering from an error.

Meanwhile the linux version is rock solid reliable.

I would suspect Tortoise more than SVN because I have used both VSS and Tortoise CVS (sorry have not tried SVN) on the same machine and it was 2 or

Tortoise is great but the performance could be improved.

Bring up Task Manager or better yet "perfmon" and see if you can pinpoint which process is using the most CPU time.

This may be your problem. Accessing the repository directly by files is a poor choice - it is suitable when you are using a stand-alone machine and just want to keep track of your own stuff, but it is not a good idea for accessing a server-stored repository. To keep the transactions safe, you need a lot of extra file locking and access to different files as well as the actual data files - this will be slow, especially with a large number of files in the trunk, and especially with a windows server.

The correct syntax for your access will be something like "svn://server/SrcRepos/...", so that you are actually accessing the svnserve demon rather than bypassing it with file access (as you are doing at the moment). This should be much faster.

I believe (but I'm not sure) that apache + mod_dav scales better if you have many people accessing the repository at the same time, and it can give you more flexibility for security or redirecting traffic, but otherwise svnserve is perfectly good. There is no doubt some tuning you could do with larger projects (newer versions of svn are better with binary files, for example).

Also make sure you are versioning the source code, not object code, listing files, etc. That will make a huge difference to the size of the repository, the speed of checkins and checkouts, and the ease of use of features such as differences and merges.

mvh.,

David

I am using one subversion server on windows XP, and three clients on windows XP machines, connected through a Gigabit ethernet. Works fine and fast.

Regards,

Zara

Thanks to all for the replies. David your suggestions may help. I'll give that a try. Hopefully it will make the difference.

Scott

Thanks, that was the solution. Now it is faster than VSS. Here are some test results for comparison.

VSS 7 mins 21 secs, 5269 files, 297 MB.

SVN 5 mins 0 secs, 5472 files, 386 MB.

SVN is notably faster but I am a little confused by the file count and total size. The size difference seems to be all in a folder it created called "Labels". This has earlier versions of one sub project. I assume this is a result of the conversion from the VSS archive to the SVN. I'd welcome comments on this.

Scott

In addition to what others said, the two cases you describe are not representative of SVN's performance or "real life" usage.

Converting or importing a project into an Subversion repository is a vary rare operation, checking out a whole project is less so, but still much less frequent than updating a checked-out tree or committing back changes.

Both conversion and full check-outs are very slow operations. Converting a larger project than the one you describe from CVS to SVN took me more than 1 and 1/2 hours. (I have no experience with SourceSafe) But again, this is done only once.

SVN checkouts are slower than CVS checkouts, that is mainly because SVN creates much larger local information files.

After a local sandbox is set up, normal check-out / update / commit operations are very fast and not worse than other SCM systems I have used in the past.

Roberto Waltman

Yes, with servers running on both Windows XP (svnserve running as a service) and Mac OS X 10.4 (using apache 2). Clients are Windows and OS X 10.4. works flawlessly.

When you say "speed is unacceptably slow," what exactly are you doing? Are you checking out the entire repository (there is no point in doing this) or the trunk or a branch of an individual project?

"export" has a specific meaning in Subversion ... it means "grab the files from the server without any of the stuff that enables version control" (in other words, it does not create .svn subdirectories). So, hopefully you did a checkout.

Your problem is that you've got the server running, yet you're not using it. You should never use the file:// access method; always use svn://server/ mechanism. file:// access is much slower than going through the server.

-a

Do you (or anyone) know if this is true even when the files are on the same machine?

There may be files that are by default not included in the archive (such as common backup file extensions) - perhaps that is catching you out? I've never had the "pleasure" of using VSS, so I haven't needed to do conversions. But there is a great deal of documentation on subversion on the website, so if there are file types intentionally omitted by default, it will be noted there. I seem to remember something about changing the svn directories on the clients to something other than .svn if you are using Microsoft's tools, but I don't know the details. Anyway, the whole subversion book is free on-line, although I also recommend buying it (for breakfast table reading, and for the warm fuzzy feeling of having helped pay for the software).

mvh.,

David