I'm mostly a lurker and svn user but I've noticed some commonality in
some of the Slashdot posts and my experience I would like to point out.
For whatever reason, the documentation causes people to feel the
primary or only method of access to the svn database is through Apache.
Maybe its due to being mentioned first in the first thing they see on
the subject (not necessarily the official manual), or talked about the
most. Whatever the cause, its definitely a problem, as I'm sure many
people would be happy to run svnserve, and would definitely prefer it
that way. The svnserve approach is definitely an order of magnitude
easier, especially for people migrating from CVS. Having to setup svn
with even just plain apache, let alone apache-ssl and all of its
configuration needs, is quite an experience for first timers. I
remember spending a good chunk of a day just trying to work out how to
make a long-term custom self-signed ssl cert for apache . . . Things
like that can be annoying. Then there's setting up apache auth (also
quite a task for a first timer) etc. Its just huge.
I've seen posts about dangers of running multiple users with ssh
tunneled svnserve. Whats up with that? Please tell me this is typical
slashdot misinformation. The programmer in me screams that this has to
be something that the Berekely DB libraries should be dealing with and
not Subversion. Even if this is not true, then svnserve itself should
deal with that on some level relatively easily . . .
In my world, about the only thing I'd say is missing from Subversion
is a nice clean built-in way of handling having files require exclusive
check-out. If you work with a huge amount of binary data such as
bitmaps or office documentation, its pretty much a required feature. I
know its possible to work with it as it is now, but its just not the
same. For example, two separate changes to the same bitmap need to be
made a serial process somewhere, and software is much better about
enforcing it than people ever will be. I suspect throwing another layer
between the art tools and subversion would just be too much for most
people to accept. Its hard enough selling one tool to a team. The
layered approach would have to be understood by the other useful tools
like RapidSVN and TortoiseSVN etc, and thats just not likely to be
consistent everywhere. I'd hate to pass up the 'good tool' because the
'bad tool' is the only one that can do 'layered feature X'.
I don't care what backend database svn uses as long as it scales to
a petabyte or two :) Art source plus histories can easily hit several
terrabytes now, and this is still growing quite rapidly. Right now we
are using CVS for code and a custom in-house thing for art. It would be
nice to have everything using the same system (just for ease of backup
management alone), but you can't have everything I guess.
There are obviously a lot of problems with the .svn directory name
on Windows due to the Windows shell and various other apps that are
poorly written. I know this sucks, but change the . to something else !
or # for example. They suite the purpose just as well and will
definitely work. I love making first time cvs users at work make their
.ssh directory in their home directories on their Windows boxes. Its
become a sadistic little intelligence/knowledge test I have now to see
if they can create that directory or not (and how fast they do it). You
guys didn't expect to make a Windows app without some workarounds for
stupid stuff did you?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 23 10:35:21 2004