[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: Installing SVN Server - minimum requirement

From: Ilan Yaniv <Ilan.Yaniv_at_timetoknow.org>
Date: Mon, 17 Nov 2008 11:46:48 +0200

Thank you all for your replies.
I have also used many Source Control systems (Clear Case, Perforce, Star
Team, RCS, and Harvest etc.) This is the first time that I need to use
Subversion, and I am still at the stage of learning it.

I agree; P4 is by far the best CM tool I have used.

Back to the issues,
Tag is an important tool CM needs. In star team there are two kinds of
labels. I used to have one (revision label) for the developers - this
kind of label is per file and not contains the whole repository.
The other is a view label, which I used. It was for the whole view. I
could freeze this label easily, so no one can change the label and I can
easily move the label on revisions of files - in case I need to do
changes.

Also, I can create a branch from a view label. This is something which
is a big issue to me.

I guess these problems I should issue as a new question of how I can do
a work around.

Ilan Yaniv

-----Original Message-----
From: David Weintraub [mailto:qazwart_at_gmail.com]
Sent: Sunday, November 16, 2008 10:10 PM
To: Andy Levy
Cc: Ilan Yaniv; Subversion Users
Subject: 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
Received on 2008-11-17 10:47:36 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.