On Sun, Nov 16, 2008 at 13:41, <qazwart_at_gmail.com> wrote:
> 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.
Subverison uses a binary diff algorithm for all files, text or binary.
Binaries do not always take "a lot of room" - I have quite a few 1MB+
PDFs which have revisions which are only a couple KB.
> 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.
This really depends upon what your security requirements are.
Subversion's built-in permissions are a bit broad (read-only,
read/write, and none) but to say that it has no built-in security is
false or at the very lease misleading. If you serve with Apache, you
can use any authentication mechanism Apache supports - personally I
find this to be a very good design decision, because it means you
aren't locked into something proprietary and having Yet Another
Password to remember. Hook it into your LDAP directory, your Active
Directory domain, or just plain htpasswd.
> 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.
Only if you get hung up on special meaning for revision numbers.
> 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.
See above. If you serve w/ Apache and use your LDAP/AD accounts for
Subversion access, handling password issues becomes a non-issue.
Personally I can't wait until my company cuts over to AD so I can
switch to VisualSVN Server and relinquish the user-management duties
to someone else.
You also don't have to worry about being locked into a proprietary
system, living on their upgrade treadmill, having your most valuable
assets stored in a format you can't get it from in an emergency.
---------------------------------------------------------------------
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:55:33 CET