Re: RE: Installing SVN Server - minimum requirement

On Sun, Nov 16, 2008 at 1:55 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
>> 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.

But most binaries don't "diff" cleanly. Subversion binaries tend to
take up a lot of room compared to diff'ing text files. This is not any
different from other revision control systems. However, most revision
control systems allow you to remove obsolete revisions. Subversion
does not. As long as you take this into consideration, this is not an
issue. But, you may prefer to store your built files somewhere besides
Subversion.

Nor, does this handle the issue of removing accidental commits that
contain bad data. This is a big no-no in a financial firm, but for
most companies, this is not an issue. However, it is a limitation in
Subversion.

>> 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.

Subversion itself doesn't have a built-in security system. Instead, it
relies on other packages that work with Subversion to provide
security. This can make things a bit difficult to configure. For
example, read access is handled by our Apache server, but write access
is handled by our Subversion pre-commit hook. It's a bit clumsy, but
it works.

Compare this to revision control systems that have built in security,
and you see the difference. You can set, read, write, checkout, list,
and all sort of permission in between. This permission can be easily
established in various groups and individuals. Nothing that can't be
done in Subversion, but it is definitely not as easy to do.

Of course, as you pointed out, Subversion does allow you to handle
this via outside systems which a few built in security systems don't
allow you to do. That way, you could have your Apache server handle
your security in some situations.

>> 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.

The lack of true tags is the biggest complaint developers have.
Through a hook that I wrote myself, I can allow users to create but
not modify a tag. However, if a user wants to modify a tag, they have
to tell me to change the hook's configuration.

Doing a diff between two revisions is a bit more difficult, and it
becomes more difficult to see exactly what revision where a tag was
applied. Nothing is impossible, but it is a bit more work.

Heck, SCCS didn't even have tags built into the system, and we managed
to "define" tags for revisions and branches. It isn't that you can't
use tags in Subversion. Its that the way we do tags makes it a bit
more difficult for developers to figure out.

>> 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.

Not all proprietary systems use proprietary formats. Perforce uses RCS
files for storing revision information. Its one of their big selling
points. Others like Bitkeeper use SCCS format.

As I said before, I've used and recommend Subversion in many of the
places where I consulted. Subversion has a lot going for it, but we
cannot pretend it is perfection.

--
David Weintraub
qazwart_at_gmail.com
> 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