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

Re: svnadmin rm-repo-revision [was: Re: Another request for obliterate...]

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-04-15 11:59:36 CEST

Daniel Patterson wrote:
>> On Tue, 2005-04-12 at 16:18 -0300, Nicolás Lichtmaier wrote:
>> * In my 20 years of CM experience, the "obliterate" command isn't as
>> important as the "rmver" command. Very rarely is there a need to
>> completely remove all references to a particular file. The only time
>> that ever happens is when a user accidently creates a file they didn't
>> need.
>
> Agreed. Most of the time, the thing the user wants to fix is the
> most recent commit they did.
>
> Perhaps "svnadmin rm-repo-revision N", which allows you to kill
> the most recent revision of the repository? The further back
> you have to go, the more you have to kill, which highlights the
> complexity
> of implementing a "true" obliterate command.

Indeed it is complex - and that complexity is not always as you would
imagine. Whilst what you outline above would be quite easy to implement for
FSFS, it would be quite difficult for BDB.

> I can see that this might cause all sorts of co-ordination problems
> though (working copies that are updated to revision N, which is killed
> and then replaced by revision N that is different?).

Those WC's would be totally screwed up. Some kind of intricate handling
mechanism would need to be inserted to communicate 'this node-revision no
longer available'.

> However, when
> I have users who checkin 3GB of Oracle CD images, I kind of want the
> ability to go kill that stuff from the repository sometimes...

Ouch.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 15 12:02:11 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.