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 ...
--
Johan
Received on 2018-03-26 00:33:12 CEST