> Question 1 - Is windows 2003 server support ready for "prime time" is
> anyone else using such a configuration un production. My other option
> is setting up a linux server from scratch which I would rather avoid
> right now.
Can't answer about Win2003, but I've had lots of success under Linux
using the basic "svnserve" to network the repository. I'm familiar with
Linux, so that bit was easy, and svnserve works great, including basic
user authentication, with very little configuration. You don't need
Apache to use Subversion.
> Question 2 - Is about clients. Can I use a client built for say
> version 0.31.1 with a server that is 0.35.1 if I am using http://
> access (i.e. I am NOT using file:// access). I say this because the
> most recent version of the eclipse plugin for subversion is currently
> linked against 0.31.1
Hassle the Eclipse plugin people to release a new version -- 0.31.1 is a
couple of months old now. I'm quite suprised there isn't a newer version
available. When doing Subversion integration for CC.Net, I used the
command line client and XML output so that you can upgrade your svn.exe
independently of CC.Net. This is because performance isn't an issue
(whereas with IDE integration you're doing lots of operations and so
API-level integration makes sense).
> Question 3 - recommended clients. Should we bite the bullet and use
> the command line client or are people having success with the eclipse
> plugin or tortoise clients (those are the two that I have tried). Or
> is there another non-command line client that is more stable. My
> primary concern is stability.
I've been using the command line client, mainly because I don't believe
it's a case of "biting the bullet". Developers should know how to use
their command line tools, and if using a GUI that makes things easier,
they should have an understanding of what's going on under the hood. I
personally work much faster and using the command line client, and the
guys on my team didn't have a problem using it. There are times when GUI
software is very useful -- for example when displaying diffs.
> Question 4 - Not really a question more of a request for comments. We
> have several developer's and reliability and stability are most
> important (versus having feature X). We are switching to subversion
> to ease stress not create it ;-) Please share
I've had a great experience with Subversion, moving a small team of
developers away from StarTeam. They were very happy with Subversion,
loved using it, were very productive once they'd learnt how to use it
(lots of small commits are generally best, with decent log messages) and
Subversion stood up well to managing 11,000 files with around 2,000
changes a week, on a borrowed desktop PC running Linux.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jan 6 18:49:32 2004