Re: [PATCH] Fix failing ci caused in r40202-upgrade to new func

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kannan wrote: [..] This patch upgrades ..add_component() to ..add_component2() which depends on the previous uncommitted patch [1] to canonicalize the URLs. [[[ Log: Resolve some deprecation warnings. * subversion/libsvn_ra_neon/commit.c (get_vers

Re: Standardizing python code using pylint

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 would be of crowd's interest are as follo

Re: Subversion 1.6.7 on Dec. 16.

On Dec 17, 2009, at 9: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: Subversion 1.6.7 on Dec. 16.

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. >>> >>> >> Sorry, what? Subversion will suddenly erro

Re: Subversion 1.6.7 on Dec. 16.

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. >> > > Sorry, what? Subversion will suddenly error out where it previously did > not. No matter

Re: mod_dav_svn not XML-escaping hook error messages

> 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 code 1) with output: post-revprop

Re: Subversion 1.6.7 on Dec. 16.

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. > Sorry, what? Subversion will suddenly error out where it previously did not. No matter /how/ that mergeinfo got into the repository, if we don't fix

Re: [PATCH] Replace two deprecated wc functions

On Thu, Dec 17, 2009 at 08:40:15PM +0100, Daniel Näslund wrote: > Hi! > > NOTE: This patch depends on my patch for #3390 that has not been > commited yet [1]. The external_func uses abspaths and that is fixed in > the referred patch. I have two more patches that depend on [1]. > > make check pass

Re: CRITICAL bug: svn:externals referring to a revision does not work if the referred resource is deleted or moved later.

http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html On Thu, Dec 17, 2009 at 3:02 PM, Mike Dixon wrote: > Gyorgy Foldvari wrote: >> >> echo "-r1 ^/trunk/A/D/H external/here" > ../f > > I'm not an svn developer, but if you had asked this on the users@ list, I > would have told you the

Re: CRITICAL bug: svn:externals referring to a revision does not work if the referred resource is deleted or moved later.

Gyorgy Foldvari wrote: echo "-r1 ^/trunk/A/D/H external/here" > ../f I'm not an svn developer, but if you had asked this on the users@ list, I would have told you the following: This isn't a bug; you need to use a peg revision rather than the -r syntax if you want to access paths that have

CRITICAL bug: svn:externals referring to a revision does not work if the referred resource is deleted or moved later.

I use to set svn:externals by defining revision too. But if the referenced resource is deleted in a later revision, the svn:externals stops working. svn version: 1.6.6 op sys: windows or linux Check the attached script to reproduce. Thanks in advance, Gyorgy #!/bin/sh ##

[PATCH] Replace two deprecated wc functions

Hi! NOTE: This patch depends on my patch for #3390 that has not been commited yet [1]. The external_func uses abspaths and that is fixed in the referred patch. I have two more patches that depend on [1]. make check passes with [1] applied. [[[ Replace deprecated svn_wc_{crawl_revisions4(),get_up

Re: Subversion 1.6.7 on Dec. 16.

The end result of all this discussion appears to be that 1.6.7 can roll as-is, so I will proceed to do so sometime in the next 24 hours. -Hyrum On Dec 17, 2009, at 9:26 AM, Philip Martin wrote: > Paul Burba writes: > >> Now that we correctly interpret mergeinfo with relative paths >> (r890993

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

On Thu, Dec 17, 2009 at 06:10:18PM +, Philip Martin wrote: > Daniel Näslund writes: > > > Index: subversion/libsvn_client/externals.c > > === > > --- subversion/libsvn_client/externals.c(revision 891778) > > +++ subversion/li

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

Daniel Näslund writes: > Index: subversion/libsvn_client/externals.c > === > --- subversion/libsvn_client/externals.c (revision 891778) > +++ subversion/libsvn_client/externals.c (arbetskopia) > @@ -894,53 +894,17 @@ >

[PATCH] Replace some adm_access batons in externals.c

Hi! make check passed! [[[ Use recursive locking when deleting an external. No need to make a distinction between files and dirs as the previous code did. * subversion/libsvn_client/externals.c (handle_external_item_change): Remove the adm_access functions and use svn_wc_{acqurire,release}

Re: mod_dav_svn not XML-escaping hook error messages

Philip Martin wrote: > Julian Foad writes: > > > I wrote one myself. Attached. I confirmed the bug, but I am having > > trouble testing my test. It may be to do with the test suite not quite > > properly supporting a build in a separate directory. > > mod_dav_svn and the revprop hooks have a few

Re: Roadmap for 1.7 end game?

On Thu, Dec 17, 2009 at 06:12:43PM +0100, Stefan Sperling wrote: > I still have some work to do for svn patch. The current hunk-application > code ends up ignoring valid hunks in certain situations. I already know > how I want to proceed, just need a bit of time to do it. I probably > won't have ti

Re: Roadmap for 1.7 end game?

On Thu, Dec 17, 2009 at 11:18:36AM -0500, Mark Phippard wrote: > Could someone share the big picture of what is left to do to get us to > the 1.7 release? All I know at this point is that it seems like there > is still a lot of work to do. Is there a list somewhere that is > tracking what needs t

Re: mod_dav_svn not XML-escaping hook error messages

Julian Foad writes: > I wrote one myself. Attached. I confirmed the bug, but I am having > trouble testing my test. It may be to do with the test suite not quite > properly supporting a build in a separate directory. mod_dav_svn and the revprop hooks have a few problems: http://subversion.tigri

Roadmap for 1.7 end game?

Could someone share the big picture of what is left to do to get us to the 1.7 release? All I know at this point is that it seems like there is still a lot of work to do. Is there a list somewhere that is tracking what needs to be done? Based on the count-progress.py script we really have not ma

Re: Subversion 1.6.7 on Dec. 16.

Paul Burba writes: > Now that we correctly interpret mergeinfo with relative paths > (r890993) we actually *consider* mergeinfo with relative source paths. > Where Hyrum ran into a problem there was some very dubious mergeinfo > on CHANGES in both the reintegrate source and the target: > > On th

Re: mod_dav_svn not XML-escaping hook error messages

On Mon, 2009-12-14, I (Julian Foad) wrote: > Jon Foster wrote: > > It seems that mod_dav_svn doesn't escape special XML characters like > > "<" and ">" in the error messages from hook scripts. This causes > > corrupt XML to be sent across the wire. Here's a Wireshark capture > > of the response t

Probable bug with svn copy

Hi All, I've been asked to analyse a problem we have had with subversion and come to the conclusion there is a bug in at least the client. The scenario was someone committed a new directory that made a build fail and in order to free up the build this commit was reverse merges (merge -c -)

Failing JavaHL test

One of the JavaHL tests has been failing for a while now: 1) testBasicMerge(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: Missing eligible merge info on '/home/bt/slaves/x64-centos/build/subversion/bindings/javahl/test-work/working_copies/basic_test33/branches/A/mu

Re: Subversion 1.6.7 on Dec. 16.

On Thu, Dec 17, 2009 at 8:48 AM, Philip Martin wrote: > Paul Burba writes: > >> Hyrum ran into a problem when reintegrating a branch back to 1.6.x >> using the (at the time) latest 1.6.x client.  Here is the merge he did >> (though this has a pegged source because the backport branch was >> delet

Re: Subversion 1.6.7 on Dec. 16.

Paul Burba writes: > Hyrum ran into a problem when reintegrating a branch back to 1.6.x > using the (at the time) latest 1.6.x client. Here is the merge he did > (though this has a pegged source because the backport branch was > deleted): > > 1.6.x.>svn merge ^^/subversion/branches/1.6.x-r40...@

RE: svn commit: r891672 - in /subversion/trunk/subversion: libsvn_client/commit_util.c tests/cmdline/externals_tests.py

> -Original Message- > From: style...@apache.org [mailto:style...@apache.org] > Sent: donderdag 17 december 2009 13:31 > To: comm...@subversion.apache.org > Subject: svn commit: r891672 - in /subversion/trunk/subversion: > libsvn_client/commit_util.c tests/cmdline/externals_tests.py > >

Re: WC-props problem? Commit says "specified baseline is not the latest baseline"

Regarding the "The specified baseline is not the latest baseline, so it may not be checked out." message: ASF has two Subversion hosts, one in EU and another in US. The EU one acts as a write-through proxy. The above message is displayed when the EU slave happens to be several revisions behind

Re: WC-props problem? Commit says "specified baseline is not the latest baseline"

2009/12/1 Julian Foad : > julianf: hey folks: I get a wierd error trying to commit "Wimp" status > for that failing test (basic_tests 7): > julianf: svn: The specified baseline is not the latest baseline, so it > may not be checked out. > julianf: svn: Your commit message was left in a temporary fi