Re: rep-cache sanity checks Re: Script to obliterate the most recent revision(s)

Daniel Shahaf writes: > While we're at it, do we check, before using a rep-cache reference, that the > revision:offset coordinates we obtained do in fact refer to a representation? The SHA1 collision detection code means Subversion now does very exact verification of

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

Johan Corveleyn wrote on Mon, 26 Mar 2018 00:32 +0200: > 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

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

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

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

Interesting stuff ... On Sat, Mar 24, 2018 at 8:38 PM, Daniel Shahaf 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 +: >> >> This question keeps

rep-cache sanity checks Re: Script to obliterate the most recent revision(s)

Julian Foad wrote on Fri, Mar 23, 2018 at 17:30:14 +: > Nathan Hartman wrote: > > It just occurred to me that because correct operation of the rep- > > cache is so crucial to the reliability of the system, perhaps it > > would be a good idea to make sure the rep-cache does not contain too- > >

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

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 +: > >> This question keeps coming up and I feel we should provide an accurate > >> answer, even if the procedure is not "supported".

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

Nathan Hartman wrote: It just occurred to me that because correct operation of the rep- cache is so crucial to the reliability of the system, perhaps it would be a good idea to make sure the rep-cache does not contain too- new revs as a sanity check during normal commits? Discussed before:

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

On Thu, Mar 22, 2018 at 6:24 PM, Julian Foad wrote: > TODO: > > 'svnadmin verify' doesn't detect if the rep-cache still contains too-new > revs, which would cause silent corruption during later commits if allowed > to remain in place. We should fix that. (I will file an

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

On 03/23/2018 02:04 AM, Daniel Shahaf wrote: > Julian Foad wrote on Thu, 22 Mar 2018 22:24 +: >> 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

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

I filed https://issues.apache.org/jira/browse/SVN-4730, "'svnadmin verify' should check rep-cache refers to valid revs". The following script ("rollback-1.sh") incorporates some of your suggestions: [[[ #!/bin/bash # Remove the most recent revision(s) from a repository # usage: $0 NEW_HEAD_REV #

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

Daniel Shahaf wrote on Fri, 23 Mar 2018 06:04 +: > I wonder if it would be possible to say: Run 'svnadmin freeze $SHELL'; > therein delete 'db/current', the revision files, and txns; restart all > reader processes; exit that subshell and run 'svnadmin recover'. This > would save the admin from

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

Julian Foad wrote on Thu, 22 Mar 2018 22:24 +: > 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,

Script to obliterate the most recent revision(s)

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? R=(the highest wanted revision number) 1. Any WCs (or parts of WCs) at a revision > R should first be updated back to a