I have yet under estimated the requirements of a Subversion server. In my
current company, I got an old obsolete Dell blade and installed RedHat on
it. I don't think it is even a dual core CPU. Heck, it might even be a
Pentium 4. The big concern was disk space, and I made sure it had plenty of
that.
We have about 50 users and three separate repositories serving over Apache.
Any lag users experience is all due to either the network or the fact that
Windows stinks at pulling data from a network. This server, which had been
sitting in the closet gathering dust until we used it as a Subversion
server has plenty of horsepower for our needs.
Now, for your second question of whether Subversion is really right for you.
There are several issues I have with Subversion. So far, nothing that
prevents me from using Subversion, but issues I would consider for any
company.
The biggest issue I have is the inability to completely remove a revision
or a file from the repository. In financial companies, this could be
critical. For example, someone accidentally checks in a file that contains
customer proprietary information. The only way to remove this information
in Subversion is a svnserve dump/load which brings the entire development
process to a halt. It is also an issue for sites that commit binary
versions of files. Unlike text files, binary files take up a lot of room
whenever you do a revision. Sites that tend to commit binary revisions of
files will remove older obsolete revisions in order to prevent their disk
requirements from growing beyond their abilities to keep up.
Subversion also doesn't have a built in security system. Subversion
security depends upon hooks, server setup, and can be quite difficult to
get it to behave exactly the way you want.
Subversion also doesn't have real tags. Instead, you treat a branch as a
tag which means you have to make sure people don't accidently check in
newer revisions into your tag, or else you're in trouble. It is also
difficult to see exactly what was tagged. For example, if I do a "svn cp"
of revision 2345 to a tag, the tagged revision becomes revision 5694.
Because of this, tagging is messier than it should be.
Nor, can you setup server configurations that others will follow. For
example, it would be nice to setup an autoproperties configuration that
works on a per server basis. Instead, it is up to your clients to do the
setup.
Now, none of these are impossible to overcome. And, Subversion does have a
big fat ace up its sleeve: Subversion is free. Buying Perforce for 200
people will cost you somewhere around $158,000. And, Perforce is one of the
cheapest commercial revision control systems out there.
Even more than just saving a few bucks, you don't have to worry about
licensing. With 200 people, you have at least 50 coming and going each and
every year. Every week, you have to dig out who is still at the company and
who just arrived. And, there are going to be those people who keep
forgetting their password. You could be spending a considerable amount of
time just handling account and password issues.
My recommendation, if your company is actually willing to shell out over
$150,000 for a revision control system is to evaluate Perforce which I
think is one of the top revision control systems around. It has many
similarities to Subversion (branches are stored the same way, it revisions
entire repositories as well as individual files, and it uses server side
hooks). Plus, Perforce has a few features that Subversion is missing.
Perforce handles branching and merging a bit better. Perforce allows you to
checkout the source repository in a much more flexible format. And,
Perforce has a more flexible security system.
Then, there are advantages that Subversion has: Subversion has properties
that simply work better than Perforce's method of handling similar issues.
Subversion allows a bit more flexibility in setup and use, And Subversion
doesn't have the licensing hassles.
I also like the fact that Perforce doesn't depend upon .svn or CVS style
directories which means there is a lot less crap stored in your working
directory. Of course, it means that you are more dependent upon a live
connection between the client and server, but Perforce is faster than
Subversion when it comes to moving data over the network. Then again,
Subversion clients are simpler to setup and the Subversion API seems to be
incorporated in more places.
Anyway, go ahead and evaluate Perforce, and compare it against Subversion.
If your workplace is like many of the places where I worked, they'll find
Subversion to be good enough for their needs.
On Nov 16, 2008 10:20am, Ilan Yaniv <Ilan.Yaniv_at_timetoknow.org> wrote:
> My company has more then 200 employee.
>
> Do you think that subversion - in first place is a good answer for a
>
> company at this size?
>
> What about virtual server, would you recommend this?
>
>
>
> Thanks
>
> Ilan Yaniv
>
>
>
> -----Original Message-----
>
> From: Andy Levy [mailto:andy.levy_at_gmail.com]
>
> Sent: Sunday, November 16, 2008 5:16 PM
>
> To: Ilan Yaniv
>
> Cc: Subversion Users
>
> Subject: Re: Installing SVN Server - minimum requirement
>
>
>
> On Sun, Nov 16, 2008 at 10:09, Ilan Yaniv
>
> wrote:
>
> > Hi
>
> >
>
> > I need to install SVN Server in my company.
>
> >
>
> > What is the recommended minimum requirement to run the server
>
> effectively?
>
>
>
> That depends in part upon how many users you'll have and how much data
>
> you're managing with it, but generally anything you would normally set
>
> up as a "server" will be more than sufficient. Subversion is not a
>
> "heavy" server.
>
>
>
> My original server was a box that was originally built in 2004 as a
>
> test server for a Tomcat application (running Windows 2000 or 2003).
>
> My current server is a Windows 2003 virtual machine w/ maybe 1GB of
>
> RAM. Both servers spent/spend most of their time twiddling their
>
> thumbs, but we're also a pretty small shop
>
>
>
> The most important thing is that you have enough disk space, or the
>
> ability to grow your disk space, to accommodate the growth of your
>
> repository.
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
>
Received on 2008-11-16 19:42:21 CET