Re: svn commit: r904901 - /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c

On Sun, 2010-01-31 at 00:20 +0200, Daniel Shahaf wrote: > danie...@apache.org wrote on Sat, 30 Jan 2010 at 22:08 -: > > Author: danielsh > > Date: Sat Jan 30 22:08:45 2010 > > New Revision: 904901 > > > > URL: http://svn.apache.org/viewvc?rev=904901&view=rev > > Log: > > * subversion/libsvn_fs

Re: 'svnadmin recover' with FSFS revprop packing: edge case bug

On Sun, 2010-01-31, Daniel Shahaf wrote: > fs_fs.c:recover_body() needs to be taught that the youngest revision > does not necessarily have a revprop file. The following repository > demonstrates the bug: > > % cat db/format > 5 > layout sharded 4 > % cat db/current > 3 >

Re: Obliterate - milestone 1 reached: the most basic obliteration

On Thu, 2010-01-28, Julian Foad wrote: > Please take a look at the differences between these three files if you > will. I think they show two things. > > (1) They show that the 'copies' information in the 'transactions' table > is not properly updated: the transaction still thinks it has a node th

Incubator PMC/Board report for February 2010 ("Subversion Developers" )

Dear Subversion Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 17 February 2010, 12 pm Pacific. The report for yo

Re: Commit failure via out of date proxy - issue #3561 - with Serf

On 01/29/2010 04:18 PM, Kamesh Jayachandran wrote: On 01/28/2010 09:08 PM, C. Michael Pilato wrote: Julian Foad wrote: On Thu, 2010-01-28 at 10:23 -0500, C. Michael Pilato wrote: Julian Foad wrote: On Wed, 2010-01-20, Julian Foad wrote: I have added issue #3561

Re: Commit failure via out of date proxy - issue #3561 - with Serf

Kamesh Jayachandran wrote: >>> Right. Now, that said, it might be prudent to make the same fix in Serf's >>> non-HTTPv2 codepath that Kamesh made for Neon. I mean, if there's an easy >>> client-side fix to be had, seems silly to require a server upgrade >>> instead. >>> >>> Kamesh, can you look i

Re: Commit failure via out of date proxy - issue #3561 - with Serf

On Mon, 2010-02-01 at 11:40 -0500, C. Michael Pilato wrote: > Kamesh Jayachandran wrote: > >>> Right. Now, that said, it might be prudent to make the same fix in Serf's > >>> non-HTTPv2 codepath that Kamesh made for Neon. I mean, if there's an easy > >>> client-side fix to be had, seems silly to

Re: 'svnadmin recover' with FSFS revprop packing: edge case bug

Julian Foad wrote on Mon, 1 Feb 2010 at 11:54 -: > On Sun, 2010-01-31, Daniel Shahaf wrote: > > fs_fs.c:recover_body() needs to be taught that the youngest revision > > does not necessarily have a revprop file. ... > > Found by: svnadmin_tests 13, when built with > > -DSVN_FS_FS_DEFAULT_MAX_FIL

Re: 'svnadmin recover' with FSFS revprop packing: edge case bug

I've filed this as issue #3571: http://subversion.tigris.org/issues/show_bug.cgi?id=3571 Patches welcome... Daniel Daniel Shahaf wrote on Sun, 31 Jan 2010 at 00:00 +0200: > fs_fs.c:recover_body() needs to be taught that the youngest revision > does not necessarily have a revprop file. The foll

Re: Commit failure via out of date proxy - issue #3561 - with Serf

On Mon, Feb 1, 2010 at 9:02 AM, Julian Foad wrote: >> > Committed this patch at r905326. >> >> Xlnt.  Thanks, Kamesh. > > Ah, my favourite kind of bug fix: *removing* a bunch of code (and adding > one line instead). Sweet. =) -- justin

mergeinfo regression test failures on trunk

I'm seeing lots of regression test failures. Alll the ones I've looked at involve mergeinfo notifications: ../../../../src2/subversion/tests/cmdline/merge_tests.py 1 EXPECTED STDOUT (regexp): --- Reverse-merging r3 into '.+': |--- Recording mergeinfo for reverse merge of r3 .*: |Gsvn-test-wor

Re: mergeinfo regression test failures on trunk

Philip Martin wrote: > I'm seeing lots of regression test failures. Alll the ones I've > looked at involve mergeinfo notifications: > > ../../../../src2/subversion/tests/cmdline/merge_tests.py 1 > EXPECTED STDOUT (regexp): > --- Reverse-merging r3 into '.+': > |--- Recording mergeinfo for reverse

Re: mergeinfo regression test failures on trunk

"C. Michael Pilato" writes: > Oh, I dunno. r8391162080374191731 seems a bit ... off. (But yes, the > regexps don't match -- they expect "Recording mergeinfo for reverse merge" > but get "Recording mergeinfo for merge" (no "reverse"). I didn't spot that! 8391162080374191731 is 0x747365742D6E76