Re: Function find_unmerged_mergeinfo()

On Fri, Dec 18, 2009 at 12:25 PM, Julian Foad wrote: > Paul, > > I was looking at > subversion/libsvn_client/merge.c:find_unmerged_mergeinfo() to review a > recent bug fix for back-port. > > It is said to be a "Helper for calculate_left_hand_side()", but I > noticed it seems to be basically a func

Re: Subversion 1.6.7 on Dec. 16.

On Fri, Dec 18, 2009 at 5:01 PM, Branko Čibej wrote: > Philip Martin wrote: >> Paul Burba writes: >> >>> So shouldn't the mergeinfo on this path in the old repos, >>> >>> svn pg svn:mergeinfo https://svn.collab.net/repos/svn/branches/1.6.x-r40452/chan...@40513 >>> ... >>> /trunk/C

Re: Subversion 1.6.7 on Dec. 16.

Philip Martin wrote: > Paul Burba writes: > >> So shouldn't the mergeinfo on this path in the old repos, >> >> >>> svn pg svn:mergeinfo >>> https://svn.collab.net/repos/svn/branches/1.6.x-r40452/chan...@40513 >>> >> ... >> /trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452 >

Re: svn trunk r892364: FAIL (x86-macosx-gnu shared)

Looks like a config error? JDK? -- Joe On Fri, Dec 18, 2009 at 12:31 PM, wrote: > Full details are available at: > http://crest.ics.uci.edu/buildbot/builders/x86-macosx-gnu%20shared/builds/1969 > > Author list: hwright > > Build Slave: osx10.4-gcc4.0.1-ia32 > > > Subversion Buildbot > http://c

Re: Subversion 1.6.7 on Dec. 16.

Paul Burba writes: > That does fail on 1.6.6, better replicating the error Hyrum > encountered, but it fails simply because the self-referential > mergeinfo is never considered. As I was saying in IRC this morning > this is a case where one bug (rel pathed mergeinfo not handled > correctly by sv

Re: Subversion 1.6.7 on Dec. 16.

On Fri, Dec 18, 2009 at 11:41 AM, Philip Martin wrote: > Paul Burba writes: > >> "This may all be moot because I fixed the bug in r892085 and nominated >> this for backport to 1.6.7.  I also nominated a test which reproduces >> the bug Hyrum found.  This test fails across the board on trunk, >> 1

Function find_unmerged_mergeinfo()

Paul, I was looking at subversion/libsvn_client/merge.c:find_unmerged_mergeinfo() to review a recent bug fix for back-port. It is said to be a "Helper for calculate_left_hand_side()", but I noticed it seems to be basically a function for comparing one mergeinfo catalog with another, to see what h

Re: Subversion 1.6.7 on Dec. 16.

Paul Burba writes: > "This may all be moot because I fixed the bug in r892085 and nominated > this for backport to 1.6.7. I also nominated a test which reproduces > the bug Hyrum found. This test fails across the board on trunk, > 1.6.x, and 1.6.6 without the the r892085 fix in place." I don't

Re: Subversion 1.6.7 on Dec. 16.

On Thu, Dec 17, 2009 at 10:10 PM, Branko Čibej wrote: > Paul Burba wrote: >> On Thu, Dec 17, 2009 at 5:53 PM, Branko Čibej wrote: >> >>> Paul Burba wrote: >>> Regardless, I don't think this is a true regression, just a new bug, and as such, not something that should hold up 1.6.7.

RE: mod_dav_svn not XML-escaping hook error messages

> -Original Message- > From: Jon Foster [mailto:jon.fos...@cabot.co.uk] > Sent: vrijdag 18 december 2009 12:52 > To: Philip Martin; Ivan Zhakov > Cc: Julian Foad; dev@subversion.apache.org > Subject: RE: mod_dav_svn not XML-escaping hook error messages > > Hi, > > I got the "svn: XML da

RE: mod_dav_svn not XML-escaping hook error messages

Hi, I got the "svn: XML data was not well-formed" using Cygwin's standard SVN client: > svn, version 1.6.5 (r38866) >compiled Aug 26 2009, 13:50:17 > > Copyright (C) 2000-2009 CollabNet. > Subversion is open source software, see http://subversion.tigris.org/ > This product includes software

Re: mod_dav_svn not XML-escaping hook error messages

Ivan Zhakov writes: >> That's not the error Jon reported: he saw an "invalid XML" error. Why >> the difference? >> > Probably he is using serf instead of neon. No, serf reports success even though the server hasn't set the property. $ ../../../subversion/svn/svn --password rayjandom ps -r0 --re

Re: mod_dav_svn not XML-escaping hook error messages

Julian Foad writes: >> > > My test (the test patch that I posted a couple of messages back in this > thread), running trunk without any patch to fix the bug, is producing: > > EXPECTED STDERR: > svn: post-revprop-change hook failed (exit

Re: [PATCH] Replace some adm_access batons in externals.c

Daniel Näslund writes: > On Thu, Dec 17, 2009 at 06:10:18PM +, Philip Martin wrote: >> Daniel Näslund writes: >> > >> > + SVN_ERR(svn_wc__release_write_lock(ib->ctx->wc_ctx, >> > + remove_target_abspath, >> > +

RE: svn commit: r892190 - /subversion/branches/1.6.x/STATUS

> -Original Message- > From: style...@apache.org [mailto:style...@apache.org] > Sent: vrijdag 18 december 2009 10:18 > To: comm...@subversion.apache.org > Subject: svn commit: r892190 - /subversion/branches/1.6.x/STATUS > > Author: stylesen > Date: Fri Dec 18 09:17:48 2009 > New Revision

Re: mod_dav_svn not XML-escaping hook error messages

On Fri, Dec 18, 2009 at 2:36 AM, Julian Foad wrote: >> > > My test (the test patch that I posted a couple of messages back in this > thread), running trunk without any patch to fix the bug, is producing: > > EXPECTED STDERR: > svn: post-re

Re: Standardizing python code using pylint

Bhuvaneswaran A wrote: > ping? Any comments on this proposal? > > On Sun, 2009-12-06 at 22:29 +0530, Bhuvaneswaran A wrote: > > As discussed in this email thread [1], I've come up with the pylint > > rules for standardizing the python code throughout the repository. > > > > Few of rules that woul