Jason Wong wrote on Tue, Feb 07, 2012 at 13:23:10 -0800:
> Hello.
>
> I have recently run into an issue with my subversion system (1.7.1)
> where a specific component I am trying to build has failed. I have
> had sucessful builds of this project before this issue happened since
> we upgraded to 1.
Hello and thank you for replying.
On Tue, Feb 7, 2012 at 4:04 PM, Daniel Shahaf wrote:
> Jason Wong wrote on Tue, Feb 07, 2012 at 13:23:10 -0800:
>> Any help/comments would be appreciated. Thank you.
>>
>
> As I said, I'd be interested in isolating the cause of these errors.
> Is there anything c
Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
> Hello and thank you for replying.
>
> On Tue, Feb 7, 2012 at 4:04 PM, Daniel Shahaf wrote:
> > Jason Wong wrote on Tue, Feb 07, 2012 at 13:23:10 -0800:
> >> Any help/comments would be appreciated. Thank you.
> >>
> >
> > As I said, I'd be
Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
> > Hello and thank you for replying.
> >
> > On Tue, Feb 7, 2012 at 4:04 PM, Daniel Shahaf wrote:
> > > Jason Wong wrote on Tue, Feb 07, 2012 at 13:23:10 -0800:
> > >> Any help/
Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
> > Hello and thank you for replying.
> >
> > On Tue, Feb 7, 2012 at 4:04 PM, Daniel Shahaf wrote:
> > > Jason Wong wrote on Tue, Feb 07, 2012 at 13:23:10 -0800:
> > >> Any help/
On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
>> Get xxd.exe from http://www.vim.org/ and cat.exe and sed.exe from
>> http://gnuwin32.sf.net (or from Cygwin). Delete f
On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia wrote:
> On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf wrote:
>> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
>>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
>
>>> Get xxd.exe from http://www.vim.org/ and cat.exe and se
Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia wrote:
> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf wrote:
> >> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
> >>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -08
On Wed, Feb 15, 2012 at 6:15 PM, Daniel Shahaf wrote:
> Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
>> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia wrote:
>> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf wrote:
>> >> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
Jason Wong wrote on Thu, Feb 16, 2012 at 11:42:42 -0800:
> On Wed, Feb 15, 2012 at 6:15 PM, Daniel Shahaf wrote:
> > Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
> >> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia wrote:
> >> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf wrote:
On Thu, Feb 16, 2012 at 12:14 PM, Daniel Shahaf wrote:
>
> The output from these two tells me two things:
>
> 1. The minfo-cnt value is reasonable (within a typical ballpark).
> That's relevant since minfo-cnt abnormalities were seen in another
> instance of the bug.
>
> 2. Everything else looks
On Mon, Feb 27, 2012 at 07:36:39AM -0800, Jason Wong wrote:
> This is true. We have seen the bug happen before. The first occurence
> of this that we had seen was Dec. 7th, 2011, a few days after we went
> from 1.6.16 to 1.7.1. That was the first time we had seen that happen.
> At the time, we did
On Mon, Feb 27, 2012 at 8:09 AM, Stefan Sperling wrote:
> On Mon, Feb 27, 2012 at 07:36:39AM -0800, Jason Wong wrote:
>> This is true. We have seen the bug happen before. The first occurence
>> of this that we had seen was Dec. 7th, 2011, a few days after we went
>> from 1.6.16 to 1.7.1. That was
On Mon, Feb 27, 2012 at 03:25:00PM -0800, Jason Wong wrote:
> So I think I misunderstood why the error messages were occurring.
> I had thought that there was a condition done by this check (in 1.7),
> that was erroneously causing svn to reject the attempt to check-in.
The purpose of this error is
Stefan Sperling wrote on Tue, Feb 28, 2012 at 03:18:35 +0100:
> On Mon, Feb 27, 2012 at 03:25:00PM -0800, Jason Wong wrote:
> > I guess I am wondering that if this is the case, then why is it that
> > if the check-in fails, and then we manually check it in again using
> > tortoisesvn, that it works
Daniel Shahaf wrote on Tue, Feb 28, 2012 at 07:17:04 +0200:
> Stefan Sperling wrote on Tue, Feb 28, 2012 at 03:18:35 +0100:
> > On Mon, Feb 27, 2012 at 03:25:00PM -0800, Jason Wong wrote:
> > > I guess I am wondering that if this is the case, then why is it that
> > > if the check-in fails, and the
Jason Wong wrote on Mon, Feb 27, 2012 at 07:36:39 -0800:
> On Thu, Feb 16, 2012 at 12:14 PM, Daniel Shahaf wrote:
>
> >
> > The output from these two tells me two things:
> >
> > 1. The minfo-cnt value is reasonable (within a typical ballpark).
> > That's relevant since minfo-cnt abnormalities we
On Tue, Feb 28, 2012 at 3:07 AM, Daniel Shahaf wrote:
> Jason Wong wrote on Mon, Feb 27, 2012 at 07:36:39 -0800:
> > On Thu, Feb 16, 2012 at 12:14 PM, Daniel Shahaf
> wrote:
> >
> > >
> > > The output from these two tells me two things:
> > >
> > > 1. The minfo-cnt value is reasonable (within a
Justin, Jason,
Some things you could do are:
- What RA method do you use? svn:// or http://?
- Are the failing revisions always small (eg: just a URL-URL copy),
or always large (eg: results of a merge)?
- Do you have any caching enabled at the OS filesystem layer or
below it?
- Did you co
On Wed, Feb 29, 2012 at 10:15 AM, Daniel Shahaf wrote:
> Justin, Jason,
>
> Some things you could do are:
>
> - What RA method do you use? svn:// or http://?
>
>
http://
> - Are the failing revisions always small (eg: just a URL-URL copy),
> or always large (eg: results of a merge)?
>
>
As me
Justin Johnson wrote on Wed, Feb 29, 2012 at 10:25:38 -0600:
> On Wed, Feb 29, 2012 at 10:15 AM, Daniel Shahaf wrote:
> > - Are the failing revisions always small (eg: just a URL-URL copy),
> > or always large (eg: results of a merge)?
> >
> >
> As mentioned before, so far it appears to be 1) cre
On Wed, Feb 29, 2012 at 10:35 AM, Daniel Shahaf wrote:
> Justin Johnson wrote on Wed, Feb 29, 2012 at 10:25:38 -0600:
> > On Wed, Feb 29, 2012 at 10:15 AM, Daniel Shahaf
> wrote:
> > > - Are the failing revisions always small (eg: just a URL-URL copy),
> > > or always large (eg: results of a me
Justin Johnson wrote on Wed, Feb 29, 2012 at 11:11:18 -0600:
> On Wed, Feb 29, 2012 at 10:35 AM, Daniel Shahaf wrote:
>
> > Justin Johnson wrote on Wed, Feb 29, 2012 at 10:25:38 -0600:
> > > On Wed, Feb 29, 2012 at 10:15 AM, Daniel Shahaf
> > wrote:
> > > > - Are the failing revisions always sma
On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf wrote:
> Justin Johnson wrote on Wed, Feb 29, 2012 at 11:11:18 -0600:
> > On Wed, Feb 29, 2012 at 10:35 AM, Daniel Shahaf
> wrote:
> >
> > > Justin Johnson wrote on Wed, Feb 29, 2012 at 10:25:38 -0600:
> > > > On Wed, Feb 29, 2012 at 10:15 AM, Dani
On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson wrote:
> On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf wrote:
>
>> Justin Johnson wrote on Wed, Feb 29, 2012 at 11:11:18 -0600:
>> > On Wed, Feb 29, 2012 at 10:35 AM, Daniel Shahaf
>> wrote:
>> >
>> > > Justin Johnson wrote on Wed, Feb 29, 2012 a
>
> > > > > - Are the failing revisions always small (eg: just a URL-URL copy),
>>> > > > > or always large (eg: results of a merge)?
>>> > > > >
>>> > > > >
>>> > > > As mentioned before, so far it appears to be 1) create a tag by
>>> copying
>>> > > an
>>> > > > entire working copy of a branch t
Justin Johnson wrote on Thu, Mar 01, 2012 at 08:28:20 -0600:
> To make sure I understand the issue, should I be concerned about the
> repositories and our ability to reproduce the history or recover from any
> corruption that this bug may have caused?
The only known (and predicted) effect of the e
On Tue, Feb 28, 2012 at 1:07 AM, Daniel Shahaf wrote:
> Jason Wong wrote on Mon, Feb 27, 2012 at 07:36:39 -0800:
>> On Thu, Feb 16, 2012 at 12:14 PM, Daniel Shahaf wrote:
>>
>> >
>> > The output from these two tells me two things:
>> >
>> > 1. The minfo-cnt value is reasonable (within a typical b
Justin Johnson wrote on Thu, Mar 01, 2012 at 07:45:08 -0600:
> On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson
> wrote:
> > On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf wrote:
> >> ... so please try SVNInMemoryCacheSize 0, and see if that makes the
> >> issue less frequent.
> >>
> >
> > I'm a
Daniel Shahaf wrote on Wed, Feb 29, 2012 at 18:15:41 +0200:
> Justin, Jason,
>
> Some things you could do are:
>
> - What RA method do you use? svn:// or http://?
>
Justin, what operating system does your server run?
Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
> I have had a developer here create a build of the latest SVN code
> with your changes you mentioned in r1294470 for the svnadmin verify
Okay, that's great news, for two reasons:
1. It means building svn on windows isn't as painful as it u
Daniel Shahaf wrote on Fri, Mar 02, 2012 at 12:21:46 +0200:
> Daniel Shahaf wrote on Wed, Feb 29, 2012 at 18:15:41 +0200:
> > Justin, Jason,
> >
> > Some things you could do are:
> >
> > - What RA method do you use? svn:// or http://?
> >
>
> Justin, what operating system does your server run?
On Fri, Mar 2, 2012 at 3:41 AM, Daniel Shahaf wrote:
> Justin Johnson wrote on Thu, Mar 01, 2012 at 07:45:08 -0600:
> > On Wed, Feb 29, 2012 at 4:14 PM, Justin Johnson <
> justinandto...@gmail.com>wrote:
> > > On Wed, Feb 29, 2012 at 11:22 AM, Daniel Shahaf
> wrote:
> > >> ... so please try SVNI
On Fri, Mar 2, 2012 at 6:21 AM, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Fri, Mar 02, 2012 at 12:21:46 +0200:
> > Daniel Shahaf wrote on Wed, Feb 29, 2012 at 18:15:41 +0200:
> > > Justin, Jason,
> > >
> > > Some things you could do are:
> > >
> > > - What RA method do you use? svn:// or htt
On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf wrote:
> Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
>> I have had a developer here create a build of the latest SVN code
>> with your changes you mentioned in r1294470 for the svnadmin verify
>
> Okay, that's great news, for two reasons:
Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf wrote:
> > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
> >> I have had a developer here create a build of the latest SVN code
> >> with your changes you mentioned in r1294470 for t
On Fri, Mar 2, 2012 at 8:12 AM, Daniel Shahaf wrote:
> Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
>> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf wrote:
>> > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
>> >> I have had a developer here create a build of the latest SVN
Hey Jason,
I'm also facing a similar problem.I'm working on a project
where the svn implementation is on the server side.Since svn
merge(reintegration only required for my project) reqiures a local working
copy, I maintain one working copy folder for each user, which I switch to
Jason Wong wrote on Tue, Mar 13, 2012 at 06:57:59 -0700:
> On Fri, Mar 2, 2012 at 8:12 AM, Daniel Shahaf wrote:
> > Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
> >> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf wrote:
> >> > Jason Wong wrote on Thu, Mar 01, 2012 at 10:01:26 -0800:
>
subu7890 wrote on Tue, Mar 13, 2012 at 21:51:17 -0700:
> Hey Jason,
> I'm also facing a similar problem.I'm working on a project
> where the svn implementation is on the server side.Since svn
> merge(reintegration only required for my project) reqiures a local working
> copy, I m
On Wed, Mar 14, 2012 at 5:15 PM, Daniel Shahaf wrote:
> Jason Wong wrote on Tue, Mar 13, 2012 at 06:57:59 -0700:
>> On Fri, Mar 2, 2012 at 8:12 AM, Daniel Shahaf wrote:
>> > Jason Wong wrote on Fri, Mar 02, 2012 at 07:32:38 -0800:
>> >> On Fri, Mar 2, 2012 at 2:58 AM, Daniel Shahaf wrote:
>> >>
[ cc += dev@. summary for dev@: investigating issue #4129: predecessor
count of rN is not incremented by one wrt that of r(N-1); see
http://subversion.tigris.org/issues/show_bug.cgi?id=4129 ]
Jason Wong wrote on Thu, Mar 15, 2012 at 07:57:47 -0700:
> On Wed, Mar 14, 2012 at 5:15 PM, Daniel Shahaf
Daniel Shahaf writes:
>> From what is there so far, yes. We do have different operations
>> occurring at the same time, but for these ones, I see MERGE and DELETE
>> verbs overlapping in the same or near time intervals according to the
>> Apache logs. I just did a quick look in the Apache logs du
shashank subramaniam wrote on Mon, Mar 19, 2012 at 20:29:47 +0530:
> Hey,
> We tried looping as a solution to the ''Predescessor
> Count for the root node revision is wrong' error (We looped the commit
> alone till it is commited).This works, but if 100 people try to commit to
Hello Daniel, Philip.
I have been following the thread: "#4129 is reproducible Re:
predecessor count for the root node-revision is wrong message".
It looks like you all have it figured out now. Good job.
Do you need any more information from me at this point? Thanks.
Jason Wong.
Jason Wong wrote on Mon, Mar 19, 2012 at 13:41:19 -0700:
> Hello Daniel, Philip.
>
> I have been following the thread: "#4129 is reproducible Re:
> predecessor count for the root node-revision is wrong message".
> It looks like you all have it figured out now. Good job.
On Mon, Mar 19, 2012 at 1:56 PM, Daniel Shahaf wrote:
> Jason Wong wrote on Mon, Mar 19, 2012 at 13:41:19 -0700:
>> Hello Daniel, Philip.
>>
>> I have been following the thread: "#4129 is reproducible Re:
>> predecessor count for the root node-revision is wrong me
s reproducible Re:
> >> predecessor count for the root node-revision is wrong message".
> >> It looks like you all have it figured out now. Good job.
> >>
> >> Do you need any more information from me at this point? Thanks.
> >>
> >
> &
Daniel Shahaf wrote on Tue, Mar 20, 2012 at 00:49:06 +0200:
> The time until 1.7.5 is counted in weeks, and 1.6.18 is scheduled to be
> released next week.
>
The fix was merged to 1.6.x@HEAD today and barring surprises will be
included in 1.6.18.
On Tue, Mar 20, 2012 at 2:32 PM, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Tue, Mar 20, 2012 at 00:49:06 +0200:
> > The time until 1.7.5 is counted in weeks, and 1.6.18 is scheduled to be
> > released next week.
> >
>
> The fix was merged to 1.6.x@HEAD today and barring surprises will be
> in
Justin Johnson wrote on Thu, Mar 22, 2012 at 13:03:04 -0500:
> On Tue, Mar 20, 2012 at 2:32 PM, Daniel Shahaf wrote:
>
> > Daniel Shahaf wrote on Tue, Mar 20, 2012 at 00:49:06 +0200:
> > > The time until 1.7.5 is counted in weeks, and 1.6.18 is scheduled to be
> > > released next week.
> > >
> >
On Thu, Mar 22, 2012 at 1:13 PM, Daniel Shahaf wrote:
> Justin Johnson wrote on Thu, Mar 22, 2012 at 13:03:04 -0500:
> > On Tue, Mar 20, 2012 at 2:32 PM, Daniel Shahaf
> wrote:
> >
> > > Daniel Shahaf wrote on Tue, Mar 20, 2012 at 00:49:06 +0200:
> > > > The time until 1.7.5 is counted in weeks,
Daniel Shahaf wrote on Sun, Mar 18, 2012 at 16:28:21 +0200:
> [ cc += dev@. summary for dev@: investigating issue #4129: predecessor
> count of rN is not incremented by one wrt that of r(N-1); see
> http://subversion.tigris.org/issues/show_bug.cgi?id=4129 ]
Okay, count me happy :-) I can reprodu
Daniel Shahaf writes:
> The bug reproduced with either "ServerLimit 1" or "ThreadLimit 1" in
> httpd.conf. (That forced both commits to be served by the same process
> (resp., by different processes).) I use httpd 2.4.1 with event MPM.
I can reproduce ove ra_local:
svnadmin create repo
svn mk
Philip Martin writes:
> I can reproduce ove ra_local:
>
> svnadmin create repo
> svn mkdir -mm file://`pwd`/repo/A
> svn mkdir -mm file://`pwd`/repo/B
> svn co file://`pwd`/repo wc1
> svn co file://`pwd`/repo wc2
> svn ps svn:mergeinfo /P:2 wc1/A
> svn ps svn:mergeinfo /Q:2 wc2/B
> svn mkdir wc1/
Philip Martin wrote on Mon, Mar 19, 2012 at 17:25:22 +:
> Philip Martin writes:
>
> > I can reproduce ove ra_local:
> >
> > svnadmin create repo
> > svn mkdir -mm file://`pwd`/repo/A
> > svn mkdir -mm file://`pwd`/repo/B
> > svn co file://`pwd`/repo wc1
> > svn co file://`pwd`/repo wc2
> > sv
On 03/19/2012 01:25 PM, Philip Martin wrote:
> Philip Martin writes:
>
>> I can reproduce ove ra_local:
>>
>> svnadmin create repo
>> svn mkdir -mm file://`pwd`/repo/A
>> svn mkdir -mm file://`pwd`/repo/B
>> svn co file://`pwd`/repo wc1
>> svn co file://`pwd`/repo wc2
>> svn ps svn:mergeinfo /P:2
C. Michael Pilato wrote on Mon, Mar 19, 2012 at 13:57:51 -0400:
> Is this problem specific to the FSFS backend?
No.
% ../runpytest svnadmin mergeinfo_race --fs-type bdb
2012-03-19 20:21:44 [WARNING] CWD:
/home/daniel/src/svn/t1/subversion/tests/cmdline
2012-03-19 20:21:44 [WARNING] EXCEPTION: Fa
"C. Michael Pilato" writes:
> On 03/19/2012 01:25 PM, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> I can reproduce ove ra_local:
>>>
>>> svnadmin create repo
>>> svn mkdir -mm file://`pwd`/repo/A
>>> svn mkdir -mm file://`pwd`/repo/B
>>> svn co file://`pwd`/repo wc1
>>> svn co file://`p
Daniel Shahaf writes:
> C. Michael Pilato wrote on Mon, Mar 19, 2012 at 13:57:51 -0400:
>> Is this problem specific to the FSFS backend?
>
> No.
>
> % ../runpytest svnadmin mergeinfo_race --fs-type bdb
> 2012-03-19 20:21:44 [WARNING] CWD:
> /home/daniel/src/svn/t1/subversion/tests/cmdline
> 2012
On 03/19/2012 02:24 PM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>> Is this problem specific to the FSFS backend?
>
> Yes, I think it is.
>
> For BDB the dag_node_t type in dag.c doesn't have a node_revision
> member. When update_ancestry does svn_fs_bdb__put_node_revision it
> writes
Philip Martin wrote on Mon, Mar 19, 2012 at 18:31:41 +:
> Daniel Shahaf writes:
>
> > C. Michael Pilato wrote on Mon, Mar 19, 2012 at 13:57:51 -0400:
> >> Is this problem specific to the FSFS backend?
> >
> > No.
> >
> > % ../runpytest svnadmin mergeinfo_race --fs-type bdb
> > 2012-03-19 20:2
Philip Martin writes:
> If I use the debugger to manually set target->node_revision to NULL
> inside svn_fs_fs__dag_increment_mergeinfo_count then the commit works.
> I'm not exactly sure how all the FSFS caching layers are supposed to
> interact. Is tree.c:update_ancestry supposed to update the
Philip Martin wrote on Mon, Mar 19, 2012 at 18:45:37 +:
> Philip Martin writes:
>
> > If I use the debugger to manually set target->node_revision to NULL
> > inside svn_fs_fs__dag_increment_mergeinfo_count then the commit works.
> > I'm not exactly sure how all the FSFS caching layers are sup
Philip Martin writes:
> Moving update_ancestry from tree.c to dag.c is one way to fix the
> problem.
This was applied in r1302613. I believe this also fixes the minfo-cnt
corruption that has been observed. To reproduce apply the following
patch to the old client to allow commit to be paused:
Jason,
I've learnt yesterday something new about the minfo-cnt corruption bug:
it can manifest not only as absurdly high values (on the order of 2**70),
but as far smaller wrong increments too (such as increment of 172
instead of of 0 on one occasion).
Could you determine whether said bug has occ
Hello Daniel.
I will give it a go and let you know what I find.
Jason
On Wed, Mar 21, 2012 at 1:39 AM, Daniel Shahaf wrote:
> Jason,
>
> I've learnt yesterday something new about the minfo-cnt corruption bug:
> it can manifest not only as absurdly high values (on the order of 2**70),
> but as f
On Thu, Mar 22, 2012 at 11:32 AM, Jason Wong wrote:
> Hello Daniel.
>
> I will give it a go and let you know what I find.
>
> Jason
>
> On Wed, Mar 21, 2012 at 1:39 AM, Daniel Shahaf wrote:
>> Jason,
>>
>> I've learnt yesterday something new about the minfo-cnt corruption bug:
>> it can manifest
Jason Wong wrote on Wed, Mar 28, 2012 at 11:49:20 -0700:
> dump-noderev.pl /repo /
> -
> id: 0.0.r62104/28771
> type: dir
> pred: 0.0.r62103/28680
> count: 62071
> text: 62104 27520 1238 1238 ea635421e867454f9f7bc503c8160a2c
> cpath: /
> copyroot: 0 /
> minfo-cnt: 25707
> --
On Wed, Mar 28, 2012 at 12:00 PM, Daniel Shahaf wrote:
> Jason Wong wrote on Wed, Mar 28, 2012 at 11:49:20 -0700:
>> dump-noderev.pl /repo /
>> -
>> id: 0.0.r62104/28771
>> type: dir
>> pred: 0.0.r62103/28680
>> count: 62071
>> text: 62104 27520 1238 1238 ea635421e867454f9f7bc5
Jason Wong wrote on Fri, Mar 30, 2012 at 11:39:02 -0700:
> On Wed, Mar 28, 2012 at 12:00 PM, Daniel Shahaf wrote:
> > Jason Wong wrote on Wed, Mar 28, 2012 at 11:49:20 -0700:
> >> dump-noderev.pl /repo /
> >> -
> >> id: 0.0.r62104/28771
> >> type: dir
> >> pred: 0.0.r62103/2868
(Just changing the subject so mergeinfo gurus spot this thread too.
tldr: #4129 also explains a bug whereby FSFS minfo-cnt values were set
to the value read from uninitialized memory (and which might therefore
have been smaller than the correct value).)
Philip Martin wrote on Fri, Mar 23, 2012 at
72 matches
Mail list logo
