On 26.03.2018 00:32, Johan Corveleyn wrote: > Interesting stuff ... > > On Sat, Mar 24, 2018 at 8:38 PM, Daniel Shahaf <d...@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
