RE: Tree conflict: Add/Add on directory

Hi Philip, Thanks for the patch. With that applied, the upgrade completes but gives the wrong result. The tree conflict is reported on the parent directory, not the conflicted directory. I.e. SVN 1.6 correctly reports a tree conflict on a/b/foo/bar, but after the upgrade SVN 1.7 reports the sam

RE: Tree conflict: Add/Add on directory

[moving to dev@ from users@] Stefan Sperling wrote: > So if you got time please try the 1.7.0-alpha1 release which should hopefully be released during the next couple of days and report back. Thanks! I built trunk r1130886, which I believe is the same as alpha1. Unfortunately, it fell over during

RE: [PATCH] Use neon's system proxy detection if not explicitly specified

Dominique wrote: > On Mon, 2010-09-27 at 13:19 +0100, Jon Foster wrote: > > Better, but it'll still go wrong with Neon 0.40 or 1.00. I guess it > > needs to be something like: > > > > if test -n ["`echo "$NEON_VERSION" | $EGREP > >

RE: [PATCH] Use neon's system proxy detection if not explicitly specified

Dominique Leuenberger wrote: > On Mon, 2010-09-27 at 12:33 +0100, Jon Foster wrote: > > Hi, > > > > + if test -n ["`echo "$NEON_VERSION" | grep '^0\.29\.'`"] ; then > > + AC_DEFINE_UNQUOTED([SVN_NEON_0_29], [1], > > +

RE: [PATCH] Use neon's system proxy detection if not explicitly specified

Hi, + if test -n ["`echo "$NEON_VERSION" | grep '^0\.29\.'`"] ; then + AC_DEFINE_UNQUOTED([SVN_NEON_0_29], [1], +[Define to 1 if you have Neon 0.29 or later.]) + fi The comment says "0.29 or later" (which I think is right), but the test looks like it's checking for Neon 0.29 exactly

RE: how do i fix a broken svn repository?

Hi, This is the mailing list for development of Subversion. You want help using Subversion, so I suggest you post your question to the users@ mailing list. Posting/subscription information is here: http://subversion.apache.org/mailing-lists.html I strongly suggest you read this before you post:

RE: svnsync backwards-compatibility with older servers (Was: Re: svn commit: r999421)

Daniel wrote: > Okay; then we should document (today) that when svnsync is used with > a 1.6 server, then the admin must ensure that two instances never start > at about the same time. (unless external locking is used) > > Not sure where this would go (the site, the book, the mailing lists..) We

RE: svnsync backwards-compatibility with older servers (Was: Re: svn commit: r999421)

Hi, Daniel Shahaf wrote: > Stefan Sperling wrote on Wed, Sep 22, 2010 at 15:45:41 +0200: > > On Wed, Sep 22, 2010 at 03:33:20PM +0200, Daniel Shahaf wrote: > > > Stefan Sperling wrote on Wed, Sep 22, 2010 at 14:31:58 +0200: > > > > On Wed, Sep 22, 2010 at 01:05:24PM +0200, Daniel Shahaf wrote: > >

svnsync backwards-compatibility with older servers (Was: Re: svn commit: r999421)

Hi, svnsync has always had locking, to prevent two svnsync processes from writing to the same mirror at the same time. (If that happens, then the mirror repo gets corrupted. You have to either delete the mirror repo and resync, dump/load it, or restore from backup. Either way, there's significa

RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code

Julian Reschke wrote: > On 21.09.2010 14:12, Daniel Shahaf wrote: > > Julian Reschke wrote on Tue, Sep 21, 2010 at 13:46:13 +0200: > >> Hi, > >> > >> just two comments without having looked at the remainder of the discussion. > >> > >> 1) If you need to augment a standard HTTP response code with ad

RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code

21 September 2010 12:46 To: Jon Foster Cc: Daniel Shahaf; Subversion Development Subject: Re: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code Hi, just two comments without having looked at the remainder of the discussion. 1) If you need to augment a standard HTTP response code w

RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code

Use SVN_ERR_FS_PROP_BASEVALUE_MISMATCH error code if applicable. (svn_ra_serf__handle_multistatus_only): Initialise new member. Patch by: Jon Foster ]]] Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for

RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code

/libsvn_ra_serf/util.c (parse_dav_status): New method. (start_207): Parse DAV:status XML element. (end_207): Parse DAV:status XML element. Use SVN_ERR_BAD_OLD_VALUE error code if applicable. (svn_ra_serf__handle_multistatus_only): Initialise new member. Patch by: Jon Foster

RE: [PATCH 2/3] atomic-revprop: Change tests

Hi, Daniel Shahaf wrote: > Jon Foster wrote on Mon, Sep 20, 2010 at 12:39:31 +0100: > > Daniel Shahaf wrote: > > > Jon Foster wrote on Mon, Sep 20, 2010 at 10:48:44 +0100: > > > > [[[ > > > > Change atomic-revprop tests to look at the error number

RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code

Daniel Shahaf wrote: > Jon Foster wrote on Mon, Sep 20, 2010 at 11:01:02 +0100: > > However, there is a simpler way! The element contains > > the HTTP error code, usually "500 Internal Server Error". So we > > could pick a special HTTP status code to mean SVN_ER

RE: [PATCH 2/3] atomic-revprop: Change tests

Hi, Daniel Shahaf wrote: > Jon Foster wrote on Mon, Sep 20, 2010 at 10:48:44 +0100: > > Hi, > > > > This patch changes the tests for the atomic-revprop feature, so that > > they test the error number rather than parsing the error text. > > This doesn't work

[PATCH 3/3] atomic-revprop: Signal the error as a HTTP status code

. (end_207_element): Check for HTTP 412 status code and create a SVN_ERR_BAD_OLD_VALUE error if found. Patch by: Jon Foster ]]] Kind regards, Jon [1] More precisely, libsvn_ra_neon/util.c:wrapper_startelm_cb() raises a SVN_ERR_XML_MALFORMED "XML data

[PATCH 2/3] atomic-revprop: Change tests

n parsing the error text. * subversion/tests/cmdline/atomic-ra-revprop-change.c: (main): When printing an error, check if it's SVN_ERR_BAD_OLD_VALUE and print a special message if it is. * subversion/tests/cmdline/prop_tests.py: (FAILS_WITH_BPV): Look for the special message. Pa

[PATCH 1/3] atomic-revprop: Change error name

... this. Change to test for SVN_ERR_BAD_OLD_VALUE. (revision_props): Change to use FAILS_WITH_BOV instead of FAILS_WITH_BPV. Patch by: Jon Foster ]]] Kind regards, Jon ** This email and its attachments may be confidential and are inten

RE: git diff format support

Hi, There is a --git-diff option in Subversion Trunk, so this will probably be available in Subversion 1.7. Kind regards, Jon -Original Message- From: anatoly techtonik [mailto:techto...@gmail.com] Sent: 24 August 2010 17:35 To: Subversion Development Subject: git diff format support

RE: revprop changes and hooks

Hi, Daniel Shahaf wrote: > But I wonder if, while here, we could go further and obtain > the "expected old property value" from the RA layer (and > pass it to the pre-hook). (This probably means revving > svn_ra_change_rev_prop() the same way svn_fs_change_rev_prop() > was revved.) That will all

RE: Possible security problem with svnsync?

Hi, C. Michael Pilato wrote: > The proposed solution has been committed to trunk. That was fast! Many thanks for fixing this. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely fo

RE: Possible security problem with svnsync?

Hi, Bob Archer wrote: > Jon Foster wrote: > > I have a repository that is partially mirrored, using svnsync and > > mod_authz_svn [1]. I just realised that the administrator of the > > mirror server can bypass the authz rules I've set up on the master > > server.

Possible security problem with svnsync?

d we should document that svnsync trusts the mirror server if you only provide one URL). Kind regards, Jon Foster [1] This is documented as supported in http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt see "Q: How does svnsy

Roadmap website bugs

Hi, I've noticed a couple of problems on http://subversion.apache.org/roadmap.html The "Upcoming Releases" section could do with updating. 1.6.7 has happened; and so's the 1.7.x guess of "January 2010". I suspect the core developers now have a better idea of when 1.7.x will branch? The "releas

RE: [PATCH] Allow "cease invocation" return from Python callback for repos.svn_repos_history2()

Hi, Роман Донченко wrote: > static svn_error_t *callback_exception_error(void) > { >PyObject *svn_module = NULL, *svn_exc = NULL; >PyObject *message = NULL, *apr_err = NULL; >PyObject *exc, *exc_type, *exc_traceback; >svn_error_t *rv = NULL; > >PyErr_Fetch(&exc_type, &exc, &exc

RE: [PATCH] Add svnsync --use-external-locking option

Hi, Stefan Sperling wrote: > On Fri, Nov 27, 2009 at 04:14:08PM -0000, Jon Foster wrote: > > Add --using-external-locking option to svnsync. > Hi Jon, > > I've finally found time to take a look at this. Sorry for taking so > long. I have committed your patch in

RE: community guide redux

Hi, Justin Erenkrantz wrote: > http://subversion.apache.org/docs/community-guide/general.html This looks nice. One minor nit: is there any way you can make the word-wrapped entries in the left-nav menu more obvious? For me, it looks like this: > Participating in the > community > Theory and >

Trivial doc bug: --prefix-file option to svndumpfilter

Hi, I was just looking at 1.6.9's CHANGES file. The changes for 1.6.0 say: * add '--prefix-file' option to 'svndumpfilter' (issue #2697) But 1.6.9 doesn't list that option when I do --help. It looks like it's actually called --targets. It also says: - Server-side bugfixes: * mod_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

mod_dav_svn not XML-escaping hook error messages

Hi, I'd like to report a problem with mod_dav_svn and repository hooks. I had a bug in my post-revprop-change script, but all I saw was: > $ svn propedit --revprop -r 19 svn:log > svn: DAV request failed; it's possible that the repository's > pre-revprop-change hook either failed or is non-exist

RE: [PATCH] Add svnsync --use-external-locking option

Hi, Julian Foad wrote: > Gavin 'Beau' Baumanis wrote: > > Hi Jon, > > > > I have logged your patch into the issue tracker: #3545 > > http://subversion.tigris.org/issues/show_bug.cgi?id=3545 > > Hi Gavin. It's great that you are keeping these patches under control. I > have a couple of suggestion

RE: [PATCH] Add svnsync --use-external-locking option

Hi, -Original Message- From: Julian Foad [mailto:julianf...@btopenworld.com] Sent: 09 December 2009 13:11 To: Gavin 'Beau' Baumanis Cc: Jon Foster; dev@subversion.apache.org Subject: Re: [PATCH] Add svnsync --use-external-locking option Gavin 'Beau' Baumanis wro

RE: HEADS UP: Damaged mergeinfo in our history; likely pain in our future.

Hi, Paul Burba [ptbu...@gmail.com] wrote: > [patch snipped] If you do this, please consider adding a new capability that can be tested in the start-commit hook? I hope I don't ever get bitten by this bug. But if I do, I'll want to make absolutely sure that all my users have a SVN client that un

Is CLA needed for submitting patches?

Hi, A quick legal/management question: If I'm submitting patches to Apache Subversion, do I need to fill out a Contributor License Agreement*? Or is that only for comitters? Kind regards, Jon * http://www.apache.org/licenses/#clas

RE: Problems with mod_dav_svn and pre-revprop-change hook

://subversion.tigris.org/issues/show_bug.cgi?id=3543 Kind regards, Jon -Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: 03 December 2009 15:32 To: Jon Foster Cc: dev@subversion.apache.org Subject: Re: Problems with mod_dav_svn and pre-revprop-change hook Jon Foster wrote

Problems with mod_dav_svn and pre-revprop-change hook

Hi, I think there are 2 separate bugs in mod_dav_svn's pre-revprop-change handling. (Mostly due to problems with mod_dav). I am using Subversion 1.6.6 and Debian's Apache httpd 2.2.9, but I can't see any relevant changes in Apache httpd's SVN Trunk. Reproduction recipes are attached - demo1.sh

RE: [PATCH] Race condition in svnsync can wedge a mirror repository

Hi, Philip Martin wrote: > Branko Čibej writes: > > Do we want to support this local svnsync usage on Windows? > Yes. > > If we do, > > someone must implement reliable local locking internally. > That's easy, we just call apr_lock_file_create :) Lockfiles have a big disadvantage: If the proces

RE: [PATCH] Add svnsync --use-external-locking option

k if using external locking. (main): Handle svnsync_opt_using_external_locking option. Patch by: Jon Foster ]]] Kind regards, Jon Index: subversion/svnsync/main.c === --- subversion/svnsync/main.c (revision 884900) +++ subversion/s

[PATCH] Add svnsync --use-external-locking option

g-external-locking. (opt_baton_t): Add using_external_locking member. (initialize_cmd, synchronize_cmd, copy_revprops_cmd): Don't take the lock if using external locking. (main): Handle svnsync_opt_using_external_locking option.

[PATCH] (trivial) Stray blank line in svnsync --help sync

Hi, While adding a new option, I noticed what appears to be a stray blank line in the "svnsync --help sync" output. 2-character patch is attached. [[[ * subversion/svnsync/main.c (svnsync_options): Remove stray newline after --config-option help text. Patch by: Jon Foster ]]] Ki

RE: [PATCH] Race condition in svnsync can wedge a mirror repository

Hi, Stefan Sperling wrote: > You can use tools like lockf or lockfile (part of procmail) for that. Thankyou, I didn't know that existed. That saves me the hassle of writing and testing my own locking code. > But it only works if the synsync processes run on the host where the > target repositor

RE: [PATCH] Race condition in svnsync can wedge a mirror repository

Hi, Stefan Sperling wrote: > OK, I will commit it. Thankyou. > There is a much worse race condition, however. Yep, your mail arrived whilst I was testing this race condition in a debugger. I can confirm it's a real bug. But for me, the biggest problem with svnsync's locking right now is that

RE: [PATCH] Race condition in svnsync can wedge a mirror repository

Hi, Stefan Sperling wrote: > What about the patch below? I've tested this, and it fixes the problem. Thanks! Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the

[PATCH] Race condition in svnsync can wedge a mirror repository

7;ve tried to keep the changes minimal, because I think this might be a candidate for a Subversion 1.6.7 patch release. [[[ Fix svnsync bug that could leave repository locked. * subversion/svnsync/main.c (get_lock): Move loop exit point so we cannot drop out of the loop (and return failure) i