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:
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
Can anyone volunteer to review this important block-read fix?
(adding to CC: some people who might)
- Julian
Philip Martin wrote:
Julian Foad writes:
How do you feel about the amount of test coverage we are giving this
block-read code so far -- is it sufficient for a 1.10.0 release? And
Julian Foad wrote:
[[[
$ svn help
...
Available subcommands:
...
x-shelve (shelve)
x-unshelve (unshelve)
$ svn help shelve
x-shelve (shelve): Move local changes onto a shelf.
usage: x-shelve [--keep-local] NAME [PATH...]
I have nominated this for backport to 1.10.x. If we can get that
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
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
#
On Fri, Mar 23, 2018, 3:10 AM Daniel Shahaf wrote:
> Trying to merge trunk@HEAD into branches/swig-py3, the py2 tests pass
> but the py3 tests fail:
>
> [[[
> E/usr/lib/python3.5/unittest/case.py:629:
> ResourceWarning:
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
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,
9 matches
Mail list logo