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

Re: Script to obliterate the most recent revision(s)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 26 Mar 2018 00:32:41 +0200

Interesting stuff ...

On Sat, Mar 24, 2018 at 8:38 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> C. Michael Pilato wrote on Fri, Mar 23, 2018 at 08:46:16 -0400:
>> On 03/23/2018 02:04 AM, Daniel Shahaf wrote:
>> > Julian Foad wrote on Thu, 22 Mar 2018 22:24 +0000:
>> >> This question keeps coming up and I feel we should provide an accurate
>> >> answer, even if the procedure is not "supported".
>> >>
>> >> Any corrections to my current best effort, below?
>> >>
>> > As a first step:
>> >
>> > Check $REPOS/format, $REPOS/db/fs-type, $REPOS/db/format.
>> [...]
>> Sure sounds like you guys are well on your way to implementing 'svnadmin
>> rollback', a specific subset of what a "perfect" obliterate feature
>> would offer that also probably meets 75% of admin users' needs. Just
>> sayin'...
> How would 'svnadmin rollback' handle the "restart all reader processes" step?
> I'm concerned that users (admins) won't downdate all wc's ...

During the Aachen hackathon we brainstormed a bit about obliterate,
and figured it would be wonderful if a client, acting on a working
copy, could detect that "history has been changed". Even if only to
give an fatal error message "your working copy is broken, please check
out a new one".

So, how to detect that a working copy and the repository have a
different idea of history, so we can error out loudly and clearly?

Can it be done with current svn features?

If not, what would we need? An idea that surfaced was "Merkle trees",
or something built around it (i.e. client and server should be able to
cheaply generate a hash representing the "tree in scope" or something
like that). I have no more concrete ideas unfortunately ...

Received on 2018-03-26 00:33:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.