Re: Coping with repository bloat

[Pete Gonzalez <pg...@bluel.com>]

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.

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.
But as Subversion's job description is to "manage revisions",
I think this would be a very apropos addition.  There is nothing
strange or outlandish about people wanting to manage histories,
and I'm guessing that the reason this has not received more attention
is simply that not many people have gotten to the "big repository"
stage yet.

At the very least, since CVS has this feature ("cvs admin -o"),
Subversion should have it under the principle that Subversion
is a replacement for CVS.  :-D

Cheers,
-Pete


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Coping with repository bloat

[Scott Lawrence <sl...@pingtel.com>]

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

Re: Coping with repository bloat

[Matt Kunze <ku...@datasplice.com>]

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.

-- 

.o0O0o.__.o0O0o.__.o0O0o.__.o0O0o.__.o0O0o.__.o0O0o.__.o0O0o.
| 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