Re: Coping with repository bloat

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.   
sip:slawrence@pingtel.com
+1.781.938.5306 x162
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org