[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

End user feedback

From: Nicklas Norling <nicklas.norling_at_ifsab.se>
Date: 2004-04-28 15:46:35 CEST

Hi all.
I've been looking into the client working copies inconsistencies we have
seen since
we started using subversion and TSVN. Let's take some background first.
We have had our code for awhile in cvs and converted our cvs repo to svn.
We've been
using subversion 1.0.2 on redhat linux with http as access protocol.
We have exclusively windows clients, winxp and win2k using svn commandline
at times
but mostly TSVN.
All developer needs the code checked out to be able to do full development
and a current
working copy consists of:
Size: 344 MB
Size on disk: 517 MB
No. of files: 54 776
No. of dirs: 14 772
And this structure is expected to grow many times over, even if all of that
growth would
not have to be checked out at a time.
We have approx. 50 developers on two sites connected with a pretty bad line.
And now to the feedback.
The subversion server and apache have worked rock stabile the entire time.
I'm amazed over
how good it really works. Actually we've had no downtime as of yet.
The subversion client however has been giving us some problems, in
particular in keeping the
working copy consistens. We have at least 1-2 working copies go bad each
day. And after a lot
of looking into this we have found that most appears to be due to known bugs
in combination
with check in of files that should not be version handled.
The developers do refactor quite a lot as this is early in the project.
Large file structure with
thousands of files move at times. This means we hit bugs with recursive
locking, recursive create
of intermediate directories.
We also version handle some generated code where the generation tool decided
the case needed
to be changed from all-upper to all-lower case. That invalidated all working
We have also had problems with users not understanding the error messages
they get.
"REPORT ... /svn/!defalut...." aren't particulary usefull when trying to
commit a change. I've done
heaps of support and even I don't understand what the problems are and how
to fix them. But usually
they seem to be a result of moving files/folders or if someone checked in
file structure changes.
We've been looking into the workarounds that exist for a few of the bugs,
but it seems that it's
virtually impossible to get users to understand how to apply them and in
what situation. Possibly
due to them not knowing what is wrong to begin with.
Another major problem has been performance for us.
Doing updates/status/commit from the top level on my P4 2.4 GHz with local
access to the repo
is a matter of 1-2 minutes at most (if there is nothing to check out). But
on older PCs the is a matter
of 20-30 minutes, and on our remote site it can go from 45-90 minutes
depending on the load on the
line. This access is deemed unacceptable by developers that used cvs. It's a
lot slower in all respects.
To my horror I have discovered that as a work around they then update
smaller portions of the code
which has lead to many more build errors, and errors that take a long time
to fix as they have to do
larget updates to freshen all code.
With all this in mind I've done a few observations of my own, and have
suggestions to make, if I may
so bold as to do that?
Firstly it would be great if the dev team could spend some time in
identifying a few of those nasty
irritating bugs that makes it impossible for svn command client to keep the
working copy in sync.
Such as taking care about case problems on windows platforms, recursive
locking, creation of
intermediate paths in the repo, deletion of locked files or any other
occurance that can possible
stop a working copy from be synced. It's my feeling that this might actually
work pretty good on
unix, but unfortunately some of us are stuck with windows ;)
There is also a hidden performance gain here. Whenever the working copies
fail, the remedy that
works is to remove more and more of the file structure, running 'svn
cleanup' and 'svn up' at times
to see when the problems stop. This means a lot of code will be checked out
after such removal
further slowing things down and using valuable network bandwith.
Secondly, if that is not possible to do soon, then a overhaul of error
messages to a more informative
style that tell the user what the problem is and how to fix it (such as
identifying a bug and teaching of the
work around) might work as well.
Then when it comes to performance the design with base files that duplicates
all files does seem to
need some thinking over as I can't really see how that would work with the
speed of disks today.
It works nicely on small amount of code, but as soon as it gets large
everything seems to grind to
a halt. Perhapes this could be an option that can be turned on/off depending
on the situation.
I hope this doesn't sound too gloomy. We really like Subversion, after all,
we selected it over cvs.
We just do not like a few really annoying bugs in it :)
As it stands today, we might unfortunately end up having to go back to cvs
for awhile if we don't get things
under control. It's having a negative effect on productivity.
Are there any possibility of getting fixes for the bugs that causes the
types of problems I described
anytime soon? I haven't seen any time plan for 1.1. What's on the time
schedule in the next release?
Any comments?
Received on Wed Apr 28 15:47:15 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.