Some experiences from our perspective as users:
*** svn+ssh://:
In our company, we first set up a linux svn+ssh:// server,
accessing both from Linux and windows clients via ssh.
Result:
We had to run recovery all the time, several times per day.
(Maybe we all are too hectic and hit Ctrl-C all the time...)
Basically everyone was very angry ("we shouldn't have
switched from cvs to svn at this time", "SVN is not
in a usable state yet", ... ). I don't overstate when saying
that we all were angry, because developing our software is
hard enough, so we need that tools like vcs's "simply work".
I suppose svn+ssh and file:// are very similar and have
similar problems.
From this perspective, I understand Aaron's / Philmann (?)
complainment about quality, and I agree completely
with him that using Subversion with file:// is NOT
in a usable state yet.
*** http://
Then - especially since all the Subversion docu clearly
says that the recommended way is to use http://
- we set up Subversion in this way (Apache under Suse Linux).
Result: Perfect.
No recovery every needed, absolute stable and relyable.
I can definitely recomment Subversion (when using http://).
Using http://, now everyone of our team is very satisfied
with Subversion.
(Maybe it is a good idea to add a really BIG red warning
in the subversion book and FAQ that you should prefer
http:// and NOT use file:// or svn://)
*** Frontends:
However, in our view, there is still one major problem
when using Subversion: that both Tortoise and RapidSVN
are not in a usable state yet (from our perspective).
We all use command line svn at the moment, which is ugly,
because most of us were used to WinCVS, including me.
But this is definitely not the Subversion team's fault,
and it is also not the Tortoise / RapidSVN team's fault,
because they simply didn't have enough time yet,
and they work hard on it (therefore it is only a matter
of time).
*** Conclusions:
I draw three conclusions from this:
a) Use http:// !!!!!
b) When following a), you get a very stable and relyable
version control system, which also today is MUCH better
than CVS in basically every respect.
The Subversion team did (and does) an excellent job!!
(Including the decision that the current state
is ready for 1.0.)
c) However, one reason to stay with CVS may be
that you are used to WinCVS, because today RapidSVN
is not comparable with WinCVS yet.
If this problem outranks the advantages of Subversion,
you may prefer waiting.
Just my two cents.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 30 01:35:26 2003