Actually, instead of making it an 'svnadmin' command, would you care to
make it its own command (E.g. 'svnobliterate')? Or at least make it so
that it has no shortened form (E.g. 'co' is short for 'checkout')?
I keep looking at it and it just keeps feeling like a very big nuke...
> -----Original Message-----
> From: Max Bowsher [mailto:email@example.com]
> Sent: Monday, January 31, 2005 11:15 AM
> To: William Nagel; Karan, Cem (Civ, ARL/CISD)
> Cc: firstname.lastname@example.org
> Subject: Re: Is anyone working on "svn obliterate"?
> William Nagel wrote:
> >> Out of even more curiosity, what does it do??? I'm just a user &
> >> have no idea what it is...
> > I think the idea is that you'd be able to run "svn obliterate" and
> > completely remove a file from previous revisions.
> > Seems like an extremely dangerous activity to be able to do with a
> > simple client-level command.
> > Besides, you can already do that with svndumpfilter and a
> > dump/load. It's a pain in the butt, but retroactively
> deleting a file
> > from previous revisions should be a pain in the butt.
> > I think such a command would also be very difficult to implement,
> > because I'm pretty sure that the Subversion API doesn't
> allow client
> > programs to modify committed revisions, so it would take an
> API change
> > to do it. (A good thing IMHO)
> > -Bill Nagel
> > P.S. I meant it's a good thing that the API doesn't allow
> the changes,
> > not that changing the API to allow it would be good. :-)
> Oh, I'm sure we will get around to doing it eventually.
> But it will almost certainly be a svnadmin command, not a svn
> command, to
> ensure it is presented as an administrative maintenance
> procedure. Also, I'm
> fairly sure that it will need to acquire an exclusive lock on the
> repository, in the same way that recover does.
> One of the most intriguing problems is that there are so many
> different ways
> you can slice space and time - it's not clear what the target of an
> obliterate command should be. Should the unit of obliteration
> be a revision?
> Or a file? Or a single version of a file? And should you be
> able to break a
> thread of history in two? Or only obliterate from one end or
> the other?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jan 31 17:27:20 2005