[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Request for binary_obliterate (WAS Another request for obliterate)

From: Mike Dewhirst <miked_at_climate.com.au>
Date: 2005-04-15 08:57:32 CEST

Mike Dewhirst wrote:
> AndrÚ P÷nitz wrote:
>> Tim Hill wrote:
>>> Apart from all the oddities that David mentions, what are the *real*
>>> needs for obliterate? I can only think of a few...
> <snip>
>>> My vote on obliterate is NO.
> I think the original request for obliterate was to deal with very large
> binary files, earlier versions of which are surplus to requirements.
> My understanding is that svn doesn't try to store deltas for binary data
> the way it does for text (source) files. IIRC it stores the entire file
> each time.
> If that is correct, there might be an argument for Binary_Obliterate.
> The caveat for such a facility would perhaps need to be along the lines
> of admin-only and oyohbi
> Thinking about what I wrote above, maybe binary files could be marked by
> the user as "only_store_the_latest_version_obliterate_all_previous". If
> so, there would be no need for an obliterate anything.

OK I can see the hole in that. Subversion is a versioning system and
obliterating anything in it subverts subversion.


But what if you did let users mark stuff as
unversioned_but_keep_the_latest_version? Maybe each obliterated item
could be replaced by an entry pointing to the replacement item.

A property of the entry would be a comment to that effect. Then when
looking at the flow of events it would be clear what has happened - and
who is to blame!


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 16 02:40:33 2005

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.