feature proposal: svn:maxrevs

[McClain Looney <m...@loonsoft.com>]

In order to satisfy the somewhat dubious requirement for svn obliterate, and 
some other issues for large binary resources recently discussed on the list, 
I propose a new svn property and behavior: svn:maxrevs

Setting svn:maxrev = n (where n > 0) on a resource would indicate to svn that 
only the last n revisions of this resource should be retained.  Seemingly 
simple, this would resolve potentially excessive disk usage for large streamy 
binaries which don't diff efficiently, and for which history isn't required 
or important.

While simple in concept, such a system may have extremely weird consequences 
for copies & so on, which I am too stupid to comprehend. This proposal is 
intended in part to rectify that ;)

I am somewhat torn myself on wether this is a good idea or not, as svn is not 
meant to be an all-purpose content-management system in the first place.  
That being said, there is a large need for software projects to be able to 
live alongside large binary dependencies (cutscenes, art, large gobs of 
random data).  Indeed, this functionality is missing from cvs as well (at 
least automatically, i know about svnadmin -o).

I look forward to hearing what dev@ have to say.

Regards, 

-- 
McClain Looney
LoonSoft LLC
m@loonsoft.com

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

Re: feature proposal: svn:maxrevs

[Greg Hudson <gh...@MIT.EDU>]

On Tue, 2004-03-23 at 11:08, Ben Collins-Sussman wrote:
> But what you've proposed is a UI... I think the harder problem to tackle
> here is the implementation.  Exactly *how* do we make libsvn_fs lose
> data?  The 'svn obliterate' issue (#516) begins to discuss this
> problem.  Talking about UIs before hde database implementation, I think,
> is putting the cart before the horse.

In our current implementation, it's relatively easy to lose data as long
as you always lose the old stuff, because delta arrows always point
forwards in time.  You just replace all the old reps with empty reps.

(My current idea for a native-fs-backed filesystem does not have that
property, though; all the delta arrows would point backwards in time,
and it wouldn't be easy to lose any information.)


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

Re: feature proposal: svn:maxrevs

[McClain Looney <m...@loonsoft.com>]

On Tuesday 23 March 2004 10:08 am, Ben Collins-Sussman wrote:
> On Tue, 2004-03-23 at 10:01, McClain Looney wrote:
>
> But what you've proposed is a UI... I think the harder problem to tackle
> here is the implementation.  Exactly *how* do we make libsvn_fs lose
> data?  The 'svn obliterate' issue (#516) begins to discuss this
> problem.  Talking about UIs before hde database implementation, I think,
> is putting the cart before the horse.

nah, it just looked like i was proposing just the ui. not being a c guy, i 
have no idea what to propose to actually implement it.  i guess it could be 
restated as automated svn obliterate.  

it occurrs to me that the ripple effecty might be mitigatable by replacing the 
historical (now deleted) nodes with pointers to the next available revision. 
or is it unacceptable to suddenly have historical revisions pointing to 
different resources all of the sudden?

-- 
McClain Looney
LoonSoft LLC
m@loonsoft.com

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

Re: feature proposal: svn:maxrevs

[Ben Collins-Sussman <su...@collab.net>]

On Tue, 2004-03-23 at 10:01, McClain Looney wrote:

> I look forward to hearing what dev@ have to say.

We're talking about a feature that forces the repository database to
lose data.  My impression is that there's a general consensus that
someday, this would be a good thing to have.

But what you've proposed is a UI... I think the harder problem to tackle
here is the implementation.  Exactly *how* do we make libsvn_fs lose
data?  The 'svn obliterate' issue (#516) begins to discuss this
problem.  Talking about UIs before hde database implementation, I think,
is putting the cart before the horse.



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