Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 22:12:59 +0100:
> On 08.03.2011 21:24, Daniel Shahaf wrote:
> >Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
> >>On 08.03.2011 20:58, Daniel Shahaf wrote:
> >>>Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> >>
On 08.03.2011 21:24, Daniel Shahaf wrote:
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
On 08.03.2011 20:58, Daniel Shahaf wrote:
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-cac
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
> On 08.03.2011 20:58, Daniel Shahaf wrote:
> >Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> >while r1078365 croaks.
> >
> >r1078357 is the merging of the integrate-txdelta-caching branch.
>
> Are you packin
On 08.03.2011 20:58, Daniel Shahaf wrote:
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-caching branch.
Are you packing the repository while loading it?
What environment are you using (since I fa
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-caching branch.
Daniel Shahaf wrote on Tue, Mar 08, 2011 at 21:34:48 +0200:
> Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 20:01:56 +0100:
> > On 07.03.2011 21:47, Daniel Shahaf wrote:
> > >svn-bisect says this started in r1078366.
> > >
> > Hm. I'm unable to reproduce the issue here (64 bit linux).
> > What's mo
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 20:01:56 +0100:
> On 07.03.2011 21:47, Daniel Shahaf wrote:
> >svn-bisect says this started in r1078366.
> >
> Hm. I'm unable to reproduce the issue here (64 bit linux).
> What's more bogus is that the code changed in 1078366
> should not even get execu
On 07.03.2011 21:47, Daniel Shahaf wrote:
svn-bisect says this started in r1078366.
Hm. I'm unable to reproduce the issue here (64 bit linux).
What's more bogus is that the code changed in 1078366
should not even get executed in your scenario.
Can you try the following patch:
Index: subversio
svn-bisect says this started in r1078366.
Daniel Shahaf wrote on Mon, Mar 07, 2011 at 19:33:48 +0200:
> I reproducibly run into a checksum mismatch error when dump|load'ing the
> svn-org mirror on svn-qavm.apache.org.
>
> Background: svn-qavm hosts a mirror of the public portion of svn-org.
> Tha
I reproducibly run into a checksum mismatch error when dump|load'ing the
svn-org mirror on svn-qavm.apache.org.
Background: svn-qavm hosts a mirror of the public portion of svn-org.
That mirror was created by svnsync 1.6.6. I dumped it (using
svnadmin dump --deltas -q) and tried to load the dump
10 matches
Mail list logo