On 26.03.2018 00:32, Johan Corveleyn wrote:
> 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".
The solution to that has been known a long time: you have to invent
another number besides the revision ID — call it "data generation ID" —
that gets changed every time anything externally visible happens to the
repository data that isn't also tracked by a change in the revision ID.
Such would include:
* revprop changes
* any kind of obliterate-ish operation
The client would have to tell the server the generation ID(s) when it
describes the working copy, and the server would then have to have a way
to force the client to perform the equivalent of a full checkout instead
of just an update.
-- Brane
Received on 2018-03-27 13:08:08 CEST