Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <87si1gr9vf.fsf@wandisco.com>
References: 
 <CA+L=CgV_LVRjR_7+cuwOt4HaR+bQA16i8QaZDgjF8Dn5NAEiOQ@mail.gmail.com>
	<878u39ev70.fsf@wandisco.com>
	<CA+L=CgVXR_=Oi70zFrNou3zYdwqFTZG7rkDPFbT0e+7OuanM7Q@mail.gmail.com>
	<878u39i5fb.fsf@wandisco.com>
	<CA+L=CgWGz49iHetNoVYfMDH4r_79cztoRK_5XJVQnG0Q1Gu=qQ@mail.gmail.com>
	<87si1gr9vf.fsf@wandisco.com>
Date: Fri, 29 Jan 2016 12:42:53 +0200
Message-ID: 
 <CA+L=CgVUdzmf6BaaNN1u4ZmwAm8ZjWAzLLWTy2EsK+FZmh3FBA@mail.gmail.com>
Subject: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
From: Gert Kello <gert.kello@gmail.com>
To: Philip Martin <philip.martin@wandisco.com>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Content-Type: multipart/alternative; boundary=089e0122f08892246d052a76b2d6

--089e0122f08892246d052a76b2d6
Content-Type: text/plain; charset=UTF-8

On 29 January 2016 at 11:52, Philip Martin <philip.martin@wandisco.com>
wrote:

> > How can I test if the 1.9 has really corrupt sqlite db file? For me it
> > seems that it still gets updates (i.e. when I bring in new revisions with
> > svnsync.)
>
> Check the index with:
>
>   sqlite3 db/rep-cache.db "pragma integrity_check"
>

Says "ok"


> Compare the ordered list:
>
>   sqlite3 db/rep-cache.db "select hash,revision from rep_cache order by
> revision"
>
> with the 1.8 list and you may be able to identify which revisions are
> missing from the 1.9 rep-cache.  There isn't any way to fix the missing
>

They are identical up to rev 91450. And then there's a large gap between
revisions 91450 and 155838. 155838 seems to be where new "svnsync" was
started, there's gap of time stamps in revision files.
91450 does not seem to be special in term of sync sequence. About 60
revisions within same minute, previous two in same second, next one 4
seconds later

(How does svnsync work? "find last rev at source and sync up to that" or
"sync while next revision present in source"? If latter then first sync
failed for some reason... If first then it probably ran till completion.
But does it actually matter?)


> deduplication other than a dump/load, but it would be interesting to
> find out why it failed.


Should I look at some svn oog information about the revisions where is
started to fail? Anything special to look for? Or should we assume
"antivirus or something else opened the file so that svnsync was unable to
write it"? The sync for this rev has been executing in the middle of day so
it is possible I tried to peek "how big the repo is at disk".


> Which method did you use to write during sync:
> file, svn or http?
>

file:///


Gert

--089e0122f08892246d052a76b2d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 29 January 2016 at 11:52, Philip Martin <span dir=3D"ltr">&lt;<a href=3D=
"mailto:philip.martin@wandisco.com" target=3D"_blank">philip.martin@wandisc=
o.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><span class=3D"">&gt; How can I test if the 1.9 has really corrupt sq=
lite db file? For me it<br>
&gt; seems that it still gets updates (i.e. when I bring in new revisions w=
ith<br>
&gt; svnsync.)<br>
<br>
</span>Check the index with:<br>
<br>
=C2=A0 sqlite3 db/rep-cache.db &quot;pragma integrity_check&quot;<br></bloc=
kquote><div><br></div><div>Says &quot;ok&quot;<br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
Compare the ordered list:<br>
<br>
=C2=A0 sqlite3 db/rep-cache.db &quot;select hash,revision from rep_cache or=
der by revision&quot;<br>
<br>
with the 1.8 list and you may be able to identify which revisions are<br>
missing from the 1.9 rep-cache.=C2=A0 There isn&#39;t any way to fix the mi=
ssing<br>
</blockquote><div><br></div><div>They are identical up to rev 91450. And th=
en there&#39;s a large gap between revisions 91450 and 155838. 155838 seems=
 to be where new &quot;svnsync&quot; was started, there&#39;s gap of time s=
tamps in revision files. <br></div><div>91450 does not seem to be special i=
n term of sync sequence. About 60 revisions within same minute, previous tw=
o in same second, next one 4 seconds later<br><br>(How does svnsync work? &=
quot;find last rev at source and sync up to that&quot; or
 &quot;sync while next revision present in source&quot;? If latter then fir=
st sync failed for some reason... If first then it probably ran till=20
completion. But does it actually matter?)<br></div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">deduplication other than a dump/=
load, but it would be interesting to<br>
find out why it failed.=C2=A0 </blockquote><div><br></div><div>Should I loo=
k at some svn oog information about the revisions where is started to fail?=
 Anything special to look for? Or should we assume &quot;antivirus or somet=
hing else opened the file so that svnsync was unable to write it&quot;? The=
 sync for this rev has been executing in the middle of day so it is possibl=
e I tried to peek &quot;how big the repo is at disk&quot;.<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Which method =
did you use to write during sync:<br>
file, svn or http?<span class=3D""><font color=3D"#888888"><br></font></spa=
n></blockquote><div><br></div><div>file:///<br><br><br></div><div>Gert <br>=
</div></div><br></div></div>

--089e0122f08892246d052a76b2d6--