[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: Matt Kunze <kunzem_at_datasplice.com>
Date: 2004-05-14 22:47:10 CEST

Pete Gonzalez wrote:
> At 04:27 AM 5/14/2004, jpsa@jjdash.demon.co.uk wrote:
>> > All right, providing *integrated* exclusive access to unversioned files
>> > is the best argument to date. Of course, Subversion hasn't a chance of
>> > doing this until it supports exclusive locks -- my pet project for
>> 1.1 :-)
>> Some of these problems sound as if they would be neatly solved by
>> allowing svn:externals to refer to unversioned files?
> That's an interesting idea. But it would be nice to have some
> version control features such as commits, authorship, deleting
> of deadwood, metadata, etc.

The idea I was kind of thinking of implementing was to have a separate
'Builds' repository that contained the non-source binary files resulting
from a particular build. Then svn:externals can fetch the relevant
dependencies for a project.

Once this was setup, I was planning on periodically deleting this
repository if it got too large. Since I don't care about the history
this wouldn't lose any important information. Then the next nightly (or
whenever) build would start the repository anew, just smaller than before.

It would be nice if this could be a little more automated, but by
keeping the repositories separate it would at least be easier to keep
the total storage requirements under control.

| Matt Kunze                      Sometimes there's a point.|
| Build Master Fooly Fool         This is not one of those  |
| DataSplice Software Developer   times.                    |
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 15 05:28:29 2004

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

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