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". 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
