And here's another pair:
[[[
harmonia,0:~% /root/bin/dump-noderev.pl /x1/svn/asf /subversion r965497
id: 0-836401.0.r965497/8198
type: dir
pred: 0-836401.0.r965496/3747
count: 47068
text: 965497 7817 368 368 e18a7fbe8bedde647c30c288bbc02c1d
props: 866503 8246 73 0 d34667037ecfd7bab466410a1c52bda6
On 08.09.2011 20:07, Mark Phippard wrote:
This is a JavaHL issue. See the attached patch which resolves the
problem I face.
If I use the JavaHL diff API to produce a patch it fails if there are
paths in the patch with UTF8 characters in the name. Here is an
example of the Exception:
On 02.09.2011 16:30, Philip Martin wrote:
Bert also suggests changing our other indices by adding wc_id and/or
local_relpath thus allowing them to be UNIQUE. Can anyone confirm that
UNIQUE indices are better?
Just imagine, if the UNIQUE constraint did not imply an index, every
INSERT or
On 02.09.2011 22:56, Greg Stein wrote:
On Fri, Sep 2, 2011 at 13:18, Mark Phippard markp...@gmail.com wrote:
Pardon my ignorance, but in a scenario like this where we want to just
change some of the indexes, aren't we able to just bump the WC format
on the fly automatically? IOW, can't we
On 10/02/2011 03:26 PM, Branko Čibej wrote:
On 02.09.2011 16:30, Philip Martin wrote:
Bert also suggests changing our other indices by adding wc_id and/or
local_relpath thus allowing them to be UNIQUE. Can anyone confirm that
UNIQUE indices are better?
Just imagine, if the UNIQUE constraint
Here are some more instances of the mergeinfo count bug:
% f() { /root/bin/dump-noderev.pl /x1/svn/asf / $1 | grep -a minfo-cnt }
REVISION minfo-cnt of /'s noderev
r891679minfo-cnt: 34417890202
r905000minfo-cnt: 34417892519
r907500minfo-cnt:
Hi All,
To make future maintenance easier, I propose moving all 1st of Month
nightlies to a separate
http://ci.apache.org/projects/subversion/nightlies/dist/archives area away
from the current monthly
set available in http://ci.apache.org/projects/subversion/nightlies/dist .
As far as the page
tldr: The first part of this mail lists a few more instances. The
second half of this mail offers a theory that explains both modes of
corruption.
---
I've run 'svn log -ql 7000' for the following fspaths and repositories:
asf:/hadoop asf:/openejb asf:/james asf:/jackrabbit asf:/karaf
I'm trying add a basic sanity check to cover the ridiculous bogosity
where the root noderev thinks its predecessor is about 20 revisions
old...
[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===
--- subversion/libsvn_fs_fs/fs_fs.c
Daniel Shahaf wrote on Mon, Oct 03, 2011 at 01:13:52 +0200:
+ if (root_noderev-predecessor_count != -1
+ root_noderev-predecessor_count != rev);
Nothing to see here; stray semicolon.
I disable Will never be executed warnings so my compiler didn't warn
me about it. Building on another
/home/neels/svnbench/20111003-002436
Started at Mon Oct 3 00:24:36 UTC 2011
-
Results for dir levels: 5 spread: 5
Timings for 5x5_1.7.x
N min max avgoperation (unit is seconds)
6 323.44 330.10 327.03
11 matches
Mail list logo