At the risk of starting an endless rant, I'm wondering if anyone is using
Subversion (SVN) for source control?

I have been a Visual SourceSafe user for years, and it constantly worries
me. In the early years, before version 6.0, it would crash and die,
destroying your database. For the last 3 or more years it has worked very
well. But I hear stories...

Now we are considering conversion to SVN and our first trials with it are
extremely trying. We have the latest released version installed on a server
and are using TortoiseSVN on winXP as a client and the speed is unacceptably
slow. How slow? So slow I wonder if the install is bad.

On Saturday I used vss2svn to convert one of our small VSS databases to SVN.
On a local machine the project is 2400 files totaling 38 MB. Archived the
VSS database is 88 MB. It took 45 minutes to convert the db to a 310 MB
dumpfile and then well over an hour to load the dumpfile into SVN. I gave
up and went home while it finished.

Today I created a local folder and used TortoiseSVN to export a project tree
from the server onto my desktop. About 30 minutes later I killed it because
it had only loaded 63 of the 2438 files onto my machine. It really consumed
the machine and the network in the process. It had loaded 1.3 Mbytes of the
38 MB project. Visual sourcesafe loaded the entire project from the same
server in under 3 minutes.

In looking at some Task Manager performance indicators, VSS was only using
about 10% of the network bandwidth and CPU usage as subversion.

As for details, we have svnserve running on the server (not apache) and we
are making file accesses to the repository using the file://x:/SrcRepos
scheme.

Is this unusual or typical for what others are getting?

Scott

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

Not Really Me <scott@validatedqwertysoftware...xyzzycom> wrote:
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
--
pete@fenelon.com "it made about as much sense as a polythene sandwich"

On Wed, 24 Jan 2007 17:04:10 -0700, Not Really Me <scott@validatedQWERTYsoftware> wrote:


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.

"Not Really Me" <scott@validatedQWERTYsoftware...XYZZYcom> wrote in message
news:51qaehF1kfepcU1@mid.individual.net...
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
3 times slower at best.

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.

Not Really Me wrote:
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

On Wed, 24 Jan 2007 17:04:10 -0700, "Not Really Me"
<scott@validatedQWERTYsoftware...XYZZYcom> wrote:


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

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:45b873af$0$24602$8404b019@news.wineasy.se...
Thanks to all for the replies. David your suggestions may help. I'll give
that a try. Hopefully it will make the difference.

Scott

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:45b873af$0$24602$8404b019@news.wineasy.se...

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

"Not Really Me" wrote:
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

[ Please reply to the group,
return address is invalid ]

On Jan 24, 5:04 pm, "Not Really Me"
<scott@validatedQWERTYsoftware...XYZZYcom> wrote:
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

"Andy Peters" <google@latke.net> writes:

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

--

John Devereux

Not Really Me wrote:
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