Another perspective:
Prior to our adoption of Subversion and TortoiseSVN,
our team was not using a version control tool.
6 months down the road everyone is happy here, none
of our programmers had much version control experience
before, but everyone is comfortable with it now, and
can see the benefits from making the leap of faith.
Even though we had no corruption, we moved from
file:// to svn:// access a few months ago after reading
about potential issues using file:// access over a
networked repository (I read this in the TortoiseSVN
documentation, and yes, there is a big red sign:)
The move from file:// to svn:// did take some effort,
I first tried svn+ssh:// (which worked on our windows
server using cygwin-sshd) but I was unable to find a
way to invoke the svnserve -r switch from sshd, so
ended up using just svn:// access, which is working
well, as is authentication using svnserve.conf.
Folker, I'm curious to know why you consider TortoiseSVN
to be unusable in it's current state?
I have found the TortoiseSVN developers to be friendly
and responsive to suggestions (e.g. read Stefan's email
today Re: external diff in .24), so feel free to pass
on constructive comments to them via the mailing list.
Recently I was required to use CVS to work on a
sourceforge project, now I love SVN and TortoiseSVN
even more!
peace
si
-=> -----Original Message-----
-=> From: Folker Schamel [mailto:schamel23@spinor.com]
-=>
-=> 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).
-=>
-=> 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 02:56:52 2003