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

Re: Coping with repository bloat

From: Glenn Maynard <g_sub_at_zewt.org>
Date: 2004-05-14 10:18:01 CEST

On Fri, May 14, 2004 at 08:20:52AM +0100, Branko Čibej wrote:
> Are you saying that CVS handles changing binaries better than SVN?
> What's your definition of "better"?

I can remove old revisions, with "cvs admin -o". It's not perfectly clean
(it can confuse cvs update if deleted revisions are still live somewhere),
but it's fast, doesn't require repository downtime, and fulfills the most
fundamental problem I have: frees disk space for old data that I no longer
need (and no longer have space) to keep around. Subversion just can't do
that.

> No, Subversion is exactly just version control. I never understand
> what's wrong with putting the unversioned data on network filesystem.

Hmm. I find it a little hard to explain, just because it's very obvious
to me. I'll give it a shot.

(First, a disclaimer: I don't really want "no versioning". Ideally, I'd
like to be able to limit versioning. Being able to back out a couple
revisions, even for large binary files, could be useful. Fundamentally,
I just don't want the repository being bloated by ancient data--if I want
to keep old stuff around indefinitely, I'll download it and burn it to a
CD, instead of having it take up finite server space forever.)

When a new user is checking out the tree for the first time, he has to jump
some hoops to get an account created and configure SVN. Once that's done,
the entire tree can be checked out with one command run from one client;
commits and updates also always happen with the same client. Users only have
to learn how to use one interface, and only one server has to be maintained.

If a second method of transfer is introduced, everything becomes much more
complicated. Separate trees have to be checked out with different clients;
data must be arranged or configured correctly to see each other; updates and
commits happen differently depending on what kind of data you're working with.
Separate server programs have to be configured and maintained, and there are
more points of failure.

That's essentially what happens with my case of using both CVS and SVN. Each
user has to install both a CVS client and an SVN client (eg. WinCVS and TSVN)
and has to know how to use both of them, and so on. It's a huge pain.

(Substitute "CVS" with any "network filesystem".)

Pete Gonzalez seems to have a comparable situation; he may have other factors.

-- 
Glenn Maynard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 10:18:33 2004

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.