What is wrong with TortoiseSVN? I've been using it in a small team of 5
for about 6 months now. It's a really remarkable peice of software.
On Mon, 2003-12-29 at 18:33, Folker Schamel wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 25 16:03:54 2004