[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: Scott Lawrence <slawrence_at_pingtel.com>
Date: 2004-05-14 21:35:43 CEST

On Fri, 2004-05-14 at 13:59, Pete Gonzalez wrote:

> I think that probably the most general approach is the suggested
> idea for a tool that lets you fold together revision histories
> in the database, i.e. "combine all changes between Jun 1, 2003
> and Jan 1, 2004 into a single revision." With this feature, you
> could just write a check-in hook script that e.g. automatically
> deletes everything before the most recent 3 revisions for ".bmp"
> files (or files with a particular property setting, etc.).
> However, I'm guessing that this feature might lead to a lot of
> subtle complications for the current update/merging implementation.

I think it's much worse than that; subversion manages revisions that are
the entire tree, not per-file. So 'folding' the revision history of
some files and not others might well introduce subtle problems (in how
the users think, if nothing else).

I think that this whole discussion began with the fact that some parts
of the backend store become very large when large files that are not
efficiently diffed are stored. It may be that what's needed is an
attribute that tells the backend that this is one of those files - just
store a single copy of each version outside the normal diff mechansim.

Scott Lawrence
Consulting Engineer
Pingtel Corp.   
+1.781.938.5306 x162
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 21:36:12 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.