Re: [PATCH] fix kwallet-related crash when solving conflicts
On Wed, Dec 12, 2012 at 3:04 PM, Lekensteyn wrote: > Further debugging revealed that a child process of svn segfaults and that this > happens because of misuse of apr_pool_cleanup_register. That function does not > accept null helpers. I've grepped the svn repo and the kwallet auth code is > the only place where this error occurs. Thanks for the complete bug report and patch. Applied in r1421103. FYI, since 1.7.8 is in the process of releasing now this won't be included.
[PATCH] fix kwallet-related crash when solving conflicts
Hi, I experienced a segfault when trying to resolve a conflict while updating: Conflict discovered in 'somefile'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: l Process '/path/to/shell-script/merge-cmd' failed (exitwhy 6) Further debugging revealed that a child process of svn segfaults and that this happens because of misuse of apr_pool_cleanup_register. That function does not accept null helpers. I've grepped the svn repo and the kwallet auth code is the only place where this error occurs. Please see the attached patch, it was based on r1421011 and tested by applying it on top of 1.7.7. Regards, PeterIndex: subversion/libsvn_auth_kwallet/kwallet.cpp === --- subversion/libsvn_auth_kwallet/kwallet.cpp (revision 1421011) +++ subversion/libsvn_auth_kwallet/kwallet.cpp (working copy) @@ -253,7 +253,7 @@ kwallet_password_get(svn_boolean_t *done, } } - apr_pool_cleanup_register(pool, parameters, kwallet_terminate, NULL); + apr_pool_cleanup_register(pool, parameters, kwallet_terminate, apr_pool_cleanup_null); return SVN_NO_ERROR; } @@ -327,7 +327,7 @@ kwallet_password_set(svn_boolean_t *done, } } - apr_pool_cleanup_register(pool, parameters, kwallet_terminate, NULL); + apr_pool_cleanup_register(pool, parameters, kwallet_terminate, apr_pool_cleanup_null); return SVN_NO_ERROR; }
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On 12/12/2012 04:23 PM, Lieven Govaerts wrote: > You're not reading my mails at all are you? ;) > That's what I suggested before, but I found later that it will not > work because the server can force the client to use skelta mode > (SVNAllowBulkUpdates Off). I'm starting to think I must have missed some, for sure. Sorry about that. I'll re-read the whole thread (from archives) before continuing to blab on. -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)
Ben Reser wrote on Wed, Dec 12, 2012 at 13:57:30 -0800: > On Tue, Dec 11, 2012 at 5:59 PM, Ben Reser wrote: > > I'd say that replacing '\r' with a '' is wrong. That would > > change the meaning of some properties. E.G. svn:ignore, svn:externals > > which use lines to handle individual records within them. > > To be more explicit, I think you should change CR or CRLF into LF. I've applied your patch Gabriela, with a tweak to the log message and with the addition of an expected_dumpfile_path parameter. Currently the test checks what Ben said --- which is also consistent with what you and danielsh suggested in earlier emails. Naturally we can change the test's expectations if down the road we decide the correct behaviour is something else. Thanks for the patch! Daniel P.S. This thread was an unusually long one, for a patch that adds about a dozen lines of code.
Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)
On Tue, Dec 11, 2012 at 5:59 PM, Ben Reser wrote: > I'd say that replacing '\r' with a '' is wrong. That would > change the meaning of some properties. E.G. svn:ignore, svn:externals > which use lines to handle individual records within them. To be more explicit, I think you should change CR or CRLF into LF.
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On 12/12/2012 04:04 PM, Lieven Govaerts wrote:
> Note that send-all is not the solution if the server insists on skelta
> mode (see my previous comment), so if you do an update or a checkout,
> you still have to tell serf to limit to one connection.
And that's trickier than it seems, IIRC, because Ivan changed ra_serf to
recycle even the first connection as an auxiliary one once the REPORT is
completely processed.
>> svnrdump is only trying to do essentally that anyway -- a update of
>> ${NOTHING} to ${SOME_REV}. It calls svn_ra_do_update(), uses the provided
>> reporter to say "I've got nothing", then finalizes the report and away she
>> goes. Would it not be more straightforward to offer a compact API for just
>> those sorts of use-cases -- the "fake update from nothing to something"
>> use-cases?
>
> Maybe, but would anything else besides svnrdump use this new API? svn
> checkout/export solve this in a different manner already.
Well, in retrospect, I would name it something that did *not* have
"checkout" in the name: svn_ra_do_export(), or svn_ra_dump_tree(), or
something. And actually, I suspect that 'svn export' could use exactly this
function! ('svn checkout' could not, because it really *is* an update under
the hood.) But of course, it wouldn't do so because it prefers the more
performant async approach. All of which leads us back to turning away from
the send-all/non-send-all focus, and onto, as you said, limiting ourselves
to a single auxiliary fetch connection.
Still, we have to have a way to sensibly decide when to do so.
Here's a question I've been wondering for some time: should we expose to
users a configuration option for declaring the number of aux connections
ra_serf should use? I mean, Firefox has exposed such an option for years.
If we did so for Subversion, we could say, "Yeah, ra_serf+svnrdump is a bad
combination. Here's a workaround. Run it with
--config-option=servers:global:serf-max-connections=2". Or better yet (as
per my other mail in this thread), we could just hardcode that option
override in svnrdump itself.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
Mike,
On Wed, Dec 12, 2012 at 10:15 PM, C. Michael Pilato wrote:
> On 12/12/2012 03:30 PM, C. Michael Pilato wrote:
>> On 12/12/2012 03:02 PM, Lieven Govaerts wrote:
>>> On Tue, Dec 11, 2012 at 9:29 PM, C. Michael Pilato
>>> wrote:
Those technical challenges aside, I've since started to doubt the wisdom of
adding special treatment of the starting revision to this API anyway. I'll
continue pondering other options.
>>>
>>> What about my earlier suggestion?
>>
>> I considered it.
>>
>> And ... then I considered it a nasty hack.
>
> Wait a second, though. If we're talking about nasty hacks, what about this
> one: 'svnrdump dump' grows code to set the new bulk-updates config option on
> behalf of the user. :-)
You're not reading my mails at all are you? ;)
That's what I suggested before, but I found later that it will not
work because the server can force the client to use skelta mode
(SVNAllowBulkUpdates Off).
>
> Something like this:
>
> Index: subversion/svnrdump/svnrdump.c
> ===
> --- subversion/svnrdump/svnrdump.c (revision 1420957)
> +++ subversion/svnrdump/svnrdump.c (working copy)
> @@ -341,7 +341,7 @@
> apr_pool_t *pool)
> {
>svn_client_ctx_t *ctx = NULL;
> - svn_config_t *cfg_config;
> + svn_config_t *cfg_config, *cfg_servers;
>
>SVN_ERR(svn_ra_initialize(pool));
>
> @@ -357,6 +357,13 @@
>cfg_config = apr_hash_get(ctx->config, SVN_CONFIG_CATEGORY_CONFIG,
> APR_HASH_KEY_STRING);
>
> + /* Forcibly prefer bulk-updates to work around issue #4116
> + (http://subversion.tigris.org/issues/show_bug.cgi?id=4116). */
> + cfg_servers = apr_hash_get(ctx->config, SVN_CONFIG_CATEGORY_SERVERS,
> + APR_HASH_KEY_STRING);
> + svn_config_set_bool(cfg_servers, SVN_CONFIG_SECTION_GLOBAL,
> + SVN_CONFIG_OPTION_BULK_UPDATES, TRUE);
> +
Also, this setting can be set per server group by the user so
overriding the above, but I got the idea! ;)
>/* Set up our cancellation support. */
>ctx->cancel_func = check_cancel;
>
>
> --
> C. Michael Pilato
> CollabNet <> www.collab.net <> Enterprise Cloud Development
>
Lieven
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On 12/12/2012 03:30 PM, C. Michael Pilato wrote:
> On 12/12/2012 03:02 PM, Lieven Govaerts wrote:
>> On Tue, Dec 11, 2012 at 9:29 PM, C. Michael Pilato
>> wrote:
>>> Those technical challenges aside, I've since started to doubt the wisdom of
>>> adding special treatment of the starting revision to this API anyway. I'll
>>> continue pondering other options.
>>>
>>
>> What about my earlier suggestion?
>
> I considered it.
>
> And ... then I considered it a nasty hack.
Wait a second, though. If we're talking about nasty hacks, what about this
one: 'svnrdump dump' grows code to set the new bulk-updates config option on
behalf of the user. :-)
Something like this:
Index: subversion/svnrdump/svnrdump.c
===
--- subversion/svnrdump/svnrdump.c (revision 1420957)
+++ subversion/svnrdump/svnrdump.c (working copy)
@@ -341,7 +341,7 @@
apr_pool_t *pool)
{
svn_client_ctx_t *ctx = NULL;
- svn_config_t *cfg_config;
+ svn_config_t *cfg_config, *cfg_servers;
SVN_ERR(svn_ra_initialize(pool));
@@ -357,6 +357,13 @@
cfg_config = apr_hash_get(ctx->config, SVN_CONFIG_CATEGORY_CONFIG,
APR_HASH_KEY_STRING);
+ /* Forcibly prefer bulk-updates to work around issue #4116
+ (http://subversion.tigris.org/issues/show_bug.cgi?id=4116). */
+ cfg_servers = apr_hash_get(ctx->config, SVN_CONFIG_CATEGORY_SERVERS,
+ APR_HASH_KEY_STRING);
+ svn_config_set_bool(cfg_servers, SVN_CONFIG_SECTION_GLOBAL,
+ SVN_CONFIG_OPTION_BULK_UPDATES, TRUE);
+
/* Set up our cancellation support. */
ctx->cancel_func = check_cancel;
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On Wed, Dec 12, 2012 at 9:30 PM, C. Michael Pilato wrote:
> On 12/12/2012 03:02 PM, Lieven Govaerts wrote:
>> On Tue, Dec 11, 2012 at 9:29 PM, C. Michael Pilato
>> wrote:
>>> Those technical challenges aside, I've since started to doubt the wisdom of
>>> adding special treatment of the starting revision to this API anyway. I'll
>>> continue pondering other options.
>>>
>>
>> What about my earlier suggestion?
>
> I considered it.
>
> And ... then I considered it a nasty hack. Seriously, this is really not
> the kind of thing that *should* be exposed through an API.
>
>...
>svn_boolean_t honor_editor_api_promises;
>...
>
> Really? :-)
>
Depends a bit on how you name that function of course, you could call
it relax_editor_depth_first_promise(svn_boolean_t) - with default to
true. This is my reading of the conclusion of your issue 2932: we're
relaxing the rules a bit, but we think it's safe to do so we make this
the new default.
> It does occur to me that one way to work around this is to add an API that
> seems generally useful:
>
> svn_ra_do_checkout()
>
> This would be Yet Another Flavor Of Update-ish Thing, but wouldn't generate
> a reporter/reporter_baton pair, and would immediately begin driving the
> provided editor/editor_baton. And ra_serf's implementation thereof would,
> of course, use send-all mode.
Note that send-all is not the solution if the server insists on skelta
mode (see my previous comment), so if you do an update or a checkout,
you still have to tell serf to limit to one connection.
>
> svnrdump is only trying to do essentally that anyway -- a update of
> ${NOTHING} to ${SOME_REV}. It calls svn_ra_do_update(), uses the provided
> reporter to say "I've got nothing", then finalizes the report and away she
> goes. Would it not be more straightforward to offer a compact API for just
> those sorts of use-cases -- the "fake update from nothing to something"
> use-cases?
Maybe, but would anything else besides svnrdump use this new API? svn
checkout/export solve this in a different manner already.
Lieven
Re: 1.7.8 up for testing/signing
On 12/12/2012 03:20 PM, Paul Burba wrote: > Hi Ben, > > Not until after I signed this did I recall your note about migrating > off of sha1 based keys -- > http://svn.haxx.se/dev/archive-2012-10/0073.shtml Glad you said something about this, Paul! I *did* remember that we were using stronger keys, but failed to notice that I hadn't configured GPG to pick my newer 4096-bit key. Here are the updated signatures from me: ::: subversion-1.7.8.tar.gz ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJQyOz1AAoJEPXg8AH+aBMz+cAP/jQuT0/5bBIL1zBOMqAVDgNQ WvAbY97EaC7UanxNWBKJ+EwZ0zhVVv0xvihes8Y0N2/2mioeFmhC7IPPVviaRyQf fPUc6Geme5NxMZXgXAJqf8hyghiKtHxbbazaBN3bDB9ngBTBChl9YhG/fNaT+fIe 1dmCq/Vlg8V3Z2/4IOXDZMPp0jDE956chL6s597QyNEVNzSZ7piNhI0/OYKcGs45 5FPFfmHDxti77hNBbTrJXMAKcOdHtqMKkuQcljlqk1vADs+wbgtSsj7AEXQCicJ/ 54udHV0N2+6OHpzd1TXgoHjz5xDZZav+SXH/K2/5a7gpqDS3n3RA0utga9V+oUeJ GOoCkR+jOYlIA/xeHkj4Fc/VA9xmqFg0Dg1ot6+6/rM4qAoyNQln5KDP+vr/+dho jZ4+E+f6rpDRltE3molkZVJ5g5Alk6D4w8BHV+txgIR4dcAdT/P+Y5sLGkdkBqpP 3RyrdDhg2eWt5dZmm8SgDN5K1zz6mNkuRtjj59fOEFqAoEM2WUyIcu0eQtZvAIJd 1ltbLrhQvq0HWEyQFwuNfDoDSZjUoT0CjnBCKXvC7MNSBzJwEJVtrXE+dVKl+ZtL dnLr5Xf/R3NxO1hNJ/MFUMvHxZEpV24fwnm3z2yGUZTnmB4v/D6zhKX1LvKskY2a GwKVcPWJDEmC5S7QJGuw =B8zc -END PGP SIGNATURE- ::: subversion-1.7.8.tar.bz2 ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJQyOz2AAoJEPXg8AH+aBMz5VUP/jcDKa9TrWcOm+MQyoFBtv9Q kV0dUmlccv0q/uNHsoS/XFmobZudqSro6q+6yFSeL0o2jxObSTEwukNHs9FbVciM 7yzeWyuM5knwgdz+YdAJxS9l0cW/uXeo/KYUuvxVkj/4RSA1RW9DTtznbwbPUF7Z nlVNXKa2lmu89xTl69PPjOXnro/L3GMglctQivAxVJsXLBA2xWxtw4h7x5ZaNNZi QkQuxxsn77Kmah8ktJo51Rcu73+GY88JecoqHufGCDNUf12DfKAWwqqfpauFKViN rD3KwAs44uCKD4eMrUQ60yZg3vaAsZymTG2W9o2UFjVteSnHIcgK5UumqYlIFKD6 V2ewcgqn8FXYHZsC6awSVo7bDnGcSg/ivkn723LFgTotaG19VkcnvYy8WK4/SbZl cI93sq4omPvlxRziCfbrONReIhagl3oQVfRqHrwB9d+q3lEPFBfxkZ5mZtAc0XEP nNffZowcni661Rwc5Y17RUCjgD44/3l4SOpOoGPml3XTdN3eNduPhtmasgo1ukOT dfKrgM8fmeHprZztM2HnoqpDHKn5VvHYhA4aXE0Yx3dPUqOKuBucrYZASg7fVv1g FntU/4b+u3ktQ9mu2gjyAvuWzsXw9kAQbExNO1YVqAj+1YjwPoZ+ahE1JIbsl0js f804UC/0yfj2UxmHWSk/ =4BSG -END PGP SIGNATURE- And I'm about to commit the same to the dist repos. -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On 12/12/2012 03:02 PM, Lieven Govaerts wrote:
> On Tue, Dec 11, 2012 at 9:29 PM, C. Michael Pilato
> wrote:
>> Those technical challenges aside, I've since started to doubt the wisdom of
>> adding special treatment of the starting revision to this API anyway. I'll
>> continue pondering other options.
>>
>
> What about my earlier suggestion?
I considered it.
And ... then I considered it a nasty hack. Seriously, this is really not
the kind of thing that *should* be exposed through an API.
...
svn_boolean_t honor_editor_api_promises;
...
Really? :-)
It does occur to me that one way to work around this is to add an API that
seems generally useful:
svn_ra_do_checkout()
This would be Yet Another Flavor Of Update-ish Thing, but wouldn't generate
a reporter/reporter_baton pair, and would immediately begin driving the
provided editor/editor_baton. And ra_serf's implementation thereof would,
of course, use send-all mode.
svnrdump is only trying to do essentally that anyway -- a update of
${NOTHING} to ${SOME_REV}. It calls svn_ra_do_update(), uses the provided
reporter to say "I've got nothing", then finalizes the report and away she
goes. Would it not be more straightforward to offer a compact API for just
those sorts of use-cases -- the "fake update from nothing to something"
use-cases?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: 1.7.8 up for testing/signing
On 12/10/2012 05:07 PM, Ben Reser wrote: > The 1.7.8 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. Summary: +1 to release. Platform: Linux 3.2.0-34-generic-pae Ubuntu 12.04.1 (precise) Linux (x86) Python 2.7.3 Perl 5.14.2 Ruby 1.8.7 Java 1.6.0_24 Verified: I tested the following (with pre-installed dependencies): ((svn, neon, serf, local) x (fsfs, bdb)) + swig-py + javahl + swig-rb + ctypes-python SHA1 Checksums: 1e298368cc2a73337eaaf192510afa5e88a097c8 subversion-1.7.8.tar.gz 12c7d8d5414bba74c9777c4d1dae74f152df63c2 subversion-1.7.8.tar.bz2 GPG Signatures ::: subversion-1.7.8.tar.gz ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlDItF8ACgkQokEGqRcG/W5dmgCgyWcd02yhR/EQTsaavwlxDaxY UQAAoJuPpOAbZZat8SnzpZ+bcIZhedqy =9rdE -END PGP SIGNATURE- ::: subversion-1.7.8.tar.bz2 ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlDItF8ACgkQokEGqRcG/W4SkwCfahh6DQkFNIPaIp91jNG3lBRb tyYAnR/Bj/3CqVLdDgFUQ0DtIqBdJzSW =zBoS -END PGP SIGNATURE- -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: 1.7.8 up for testing/signing
On Mon, Dec 10, 2012 at 10:03 PM, Paul Burba wrote: > On Mon, Dec 10, 2012 at 5:07 PM, Ben Reser wrote: >> The 1.7.8 release artifacts are now available for testing/signing. >> Please get the tarballs from >> https://dist.apache.org/repos/dist/dev/subversion >> and add your signatures there. >> >> Thanks! > > SUMMARY: > - > +1 to release > > VERIFIED: > - > Other than the expected differences in > subversion/include/svn_version.h, > https://dist.apache.org/repos/dist/dev/subversion/subversion-1.7.8.zip > is identical to > https://svn.apache.org/repos/asf/subversion/branches/1.7.x@1419691. > > SHA1 checksum of > https://dist.apache.org/repos/dist/dev/subversion/subversion-1.7.8.zip > is 65985725f8138cc18993a9088d4ad70df6c0d816 > > TESTED: > --- > [Release-Build] x[ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ] > Ruby bindings (patched as described here: > http://svn.haxx.se/dev/archive-2011-06/0682.shtml) > JavaHL Bindings > > RESULTS: > > All Tests Pass > > PLATFORM: > - > MS Windows 7 Home Premium Service Pack 1 > Microsoft Visual Studio 2008 Version 9.0.30729.1 SP > > DEPENDENCIES: > - > APR: 1.4.6 > APR-UTIL: 1.4.1 > Neon: 0.29.5 > zlib: 1.2.4 > OpenSSL: 0.9.8q > Apache: 2.2.22 > BDB: 4.8.30 > sqlite: 3.7.7.1 > Python: 2.7.2 (ActivePython 2.7.2.5) > Perl: 5.14.2 > Ruby: ruby 1.8.7 > java: 1.6.0_21 > junit: 4.8.2 > swig: 1.3.40 > serf: 1.1.1 > > SIGNATURE: > -- > https://dist.apache.org/repos/dist/dev/subversion/subversion-1.7.8.zip: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (MingW32) > > iD8DBQBQxnLZ2RaJMFP83FURAhdgAJ4uhjXgujUQK5MCObZWanCv0y06dgCfcip4 > 9wYkft1k86LMlDaXYBRZfvk= > =EbgM > -END PGP SIGNATURE- Hi Ben, Not until after I signed this did I recall your note about migrating off of sha1 based keys -- http://svn.haxx.se/dev/archive-2012-10/0073.shtml Here's my sig using my new[1] 4069 bit RSA key (I updated subversion-1.7.8.zip.asc as well): -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQIcBAABCgAGBQJQyOCjAAoJEGTdwHFW89e8CPcQAJpAIFDDNudie0SwBvaVgBTJ BAX+SWGxAX8uHw1YTGUlTBqtfjy9K1e6tYF3HfOA/8OVzPaVLo+w6KBOQvblGvoy 0XqCel/QEtFtxLnr0O2WRQVQlIis05hTZNPbti7nYg4CPfAKfVQHTJGFwABw9n6u hUD4guSnaKJEFE0YXO4Ze8ypb9n7ByB10oFEntg5M8F7khnMccv/h+LDAjfFGiJk nXLcZflm9at9ZKaTg2DNeYHANXVz37sYvzKSdprA/JJsMu62pBZRoUYxsUQlS3CJ fGqzpqYViN3pZaEZ0xKk5IQS1/inHKn5dJOmZrBQ+8Y5Homy0S8dVEWKx4XOJBYM PfjNo95yr0vb8BT/ZesGVePl44j8KCXgFnFUcC7z3F6/iMn9+NTF+PuLlEBvFU5c aEmgFWavDq5X97GGsir0/lN4jQwBCjDLJw+l11252HRGyqpEBx78OT0we9cvYWEm ic3WLYricNfGVoJcp//i0OBtT2Ay0A/wCBrgCT6zUo9ZkwV6+94sKiq8y9PTQ37f cmU/ZijP54xevUXX4vkzUxpolZao3ZiWpWUBaLf45MIVU2nDlf2HLs74TH7IMLZP 0o56klr7t7MHZHf2kfwhtNqZ0SMLNrdTU7G7OjpGTi/C33uy9eWgRvX20NZTvJmu wWjxtQXUR8U4NqeQBsmI =A/dt -END PGP SIGNATURE- [1] Key ID: 56F3D7BC Fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
Re: [PATCH] Prevent false negative results of "make check" in Python tests
Andreas Stieger wrote on Wed, Dec 12, 2012 at 20:01:11 +:
> Hello,
>
> discussed on IRC, the patch below changes the test harness to prevent
> some false negatives when running the test suite. Specifically, if a
> python test initialisation returns in such a way that the test runner
> doesn't know how to handle the result, change to code to return a
> non-zero exit code like and, subsequently, have "make check" fail
> correctly. Reproducible by using Python < 2.5 or missing sqlite3 Python
> bindings, exit triggered by
> subversion/tests/cmdline/svntest/__init__.py. danielsh,breser hinted +1
> for this on IRC.
Go ahead and commit. It's an error path that no one should be running
into; you run into it, and you have 2 +1's, so it's a no brainer. If
anyone have issues I trust they'll do a post-commit review.
>
> [[[
> Prevent false negative results of "make check" in Python tests
>
> * build/run_tests.py
> (_run_py_test): exit non-zero like _run_c_test
> ]]]
>
> With kind regards,
> Andreas Stieger
> Index: build/run_tests.py
> ===
> --- build/run_tests.py(revision 1420930)
> +++ build/run_tests.py(working copy)
> @@ -434,7 +434,7 @@ class TestHarness:
> ('.py', 'U', imp.PY_SOURCE))
> except:
>print("Don't know what to do about " + progbase)
> - raise
> + sys.exit(1)
>
> import svntest.main
>
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On Tue, Dec 11, 2012 at 9:29 PM, C. Michael Pilato wrote: > On 12/10/2012 10:53 AM, C. Michael Pilato wrote: >> What if we revved the svn_ra_replay_range() API in such a way that it could >> now handle this "initial revision" scenario? We might add an 'incremental' >> flag that parallels what 'svnadmin dump' and 'svnrdump dump' do. This would >> get us to a single RA API used for revision replays (replay_range, instead >> of a combination of do_update + replay_range), which simplifies how replays >> are done from an API perspective. Of course, under the hood, the RA >> implementations of the new replay_range2() would probably just use the same >> update mechanics to handle that initial revision when not in incremental >> mode, but ra_serf's particular implementation would be free to choose >> "send-all" mode in this one scenario to do exactly that. > > Well, this turns out to be a little more sticky than I'd hoped. > > It's easy enough to add a "send_complete_start_revision" flag to > svn_ra_replay_range() which causes the first transmitted revision to be a > full dump of the tree as of that revision. But the svn_ra_replay_range() > API also allows folks to specific whether they want *real* content change > information, or just placeholder notifications for modified file content and > node properties. Seems kinda yucky to transmit a full tree snapshot when > the caller has asked not to get any real content mods; and we don't have a > readily available way to send a full tree snapshot sans real content. > > Those technical challenges aside, I've since started to doubt the wisdom of > adding special treatment of the starting revision to this API anyway. I'll > continue pondering other options. > What about my earlier suggestion? """ On Thu, Dec 6, 2012 at 11:04 PM, Mark Phippard wrote: >>> Is there an easy way to make svnrdump always use "sendall" mode? That >>> would remove the release blocker we have about this command not >>> working correctly with Serf and it seems like something we ought to be >>> able to implement independent of these other questions. >>> >> >> A bit of a hack, but after the config is read from file/registry and >> before svnrdump creates the ra_session we can set the global or per >> server-group "bulk-updates" option in memory to true. >> Is this for dump only? > > AFAIK, it is only dump where the svnrdump tool fails when using Serf. > Because of the Ev1 stuff. Using bulk-updates ought to avoid that > issue. Actually, my proposed hack of forcing ra_serf to use bulk update mode is not going to work. If the server has SVNAllowBulkUpdates set to Off, bulk update mode isn't available, the server will ignore any requests from the client and force skelta mode. If I remember correctly the issue here was responses arriving out of order due to multiple parallel connections. So the fix until svnrdump has moved to Ev2 is to stick to one extra connection for all the file content requests, so all of those responses arrive in sync. Don't know how easy that is to do, I wonder if we have a simple mechanism that allows a client to pass ra implementation specific options. """ It'd still require an ra API change, like guarantee_depth_first_order(), which ra_serf will use to limit the nr. of connections to 1, and probably only svnrdump will every use. > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Enterprise Cloud Development > Lieven
[PATCH] Prevent false negative results of "make check" in Python tests
Hello,
discussed on IRC, the patch below changes the test harness to prevent
some false negatives when running the test suite. Specifically, if a
python test initialisation returns in such a way that the test runner
doesn't know how to handle the result, change to code to return a
non-zero exit code like and, subsequently, have "make check" fail
correctly. Reproducible by using Python < 2.5 or missing sqlite3 Python
bindings, exit triggered by
subversion/tests/cmdline/svntest/__init__.py. danielsh,breser hinted +1
for this on IRC.
[[[
Prevent false negative results of "make check" in Python tests
* build/run_tests.py
(_run_py_test): exit non-zero like _run_c_test
]]]
With kind regards,
Andreas Stieger
Index: build/run_tests.py
===
--- build/run_tests.py (revision 1420930)
+++ build/run_tests.py (working copy)
@@ -434,7 +434,7 @@ class TestHarness:
('.py', 'U', imp.PY_SOURCE))
except:
print("Don't know what to do about " + progbase)
- raise
+ sys.exit(1)
import svntest.main
Re: 1.7.8 up for testing/signing
> http://anonscm.debian.org/viewvc/pkg-subversion/src/1.7.x/debian/patches/ (Or svn://anonscm.debian.org/pkg-subversion/src/1.7.x/debian/patches .)
Re: 1.7.8 up for testing/signing
Philip Herron writes: > Ok cool never seen these ones there was probably a much older one i was > looking at where can i download these ones? http://anonscm.debian.org/viewvc/pkg-subversion/src/1.7.x/debian/patches/ -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: 1.7.8 up for testing/signing
Ok cool never seen these ones there was probably a much older one i was looking at where can i download these ones? --Phil On 12/12/12 11:56, Philip Martin wrote: > Philip Herron writes: > >> Which patch are you referring in paticular? > > subversion-1.7.5/debian/patches/apr-abi1 > subversion-1.7.5/debian/patches/apr-abi2 > > Index: configure.ac > === > --- configure.ac (revision 1420608) > +++ configure.ac (working copy) > @@ -99,19 +99,26 @@ > if test `expr $apr_version : 2` -ne 0; then >dnl Bump the library so-version to 2 if using APR-2 >dnl (Debian uses so-version 1 for APR-1-with-largefile) > - SVN_LT_SOVERSION="-version-info 2" > + svn_lib_ver=2 >dnl APR-2 provides APRUTIL >apu_config=$apr_config >AC_SUBST(SVN_APRUTIL_INCLUDES) >AC_SUBST(SVN_APRUTIL_CONFIG, ["$apu_config"]) >AC_SUBST(SVN_APRUTIL_LIBS) >AC_SUBST(SVN_APRUTIL_PREFIX) > +elif test `expr $apr_version : 1` -ne 0; then > + svn_lib_ver=1 > + APU_VER_REGEXES=["1\."] > + SVN_LIB_APRUTIL($APU_VER_REGEXES) > else > - SVN_LT_SOVERSION="-version-info 0" > - APU_VER_REGEXES=["0\.9\.[7-9] 0\.9\.1[0-9] 1\."] > + svn_lib_ver=0 > + APU_VER_REGEXES=["0\.9\.[7-9] 0\.9\.1[0-9]"] >SVN_LIB_APRUTIL($APU_VER_REGEXES) > fi > +SVN_LT_SOVERSION="-version-info $svn_lib_ver" > AC_SUBST(SVN_LT_SOVERSION) > +AC_DEFINE_UNQUOTED(SVN_SOVERSION, $svn_lib_ver, > + [Subversion library major verson]) > > dnl Search for pkg-config > AC_PATH_PROG(PKG_CONFIG, pkg-config) > Index: subversion/libsvn_fs/fs-loader.c > === > --- subversion/libsvn_fs/fs-loader.c (revision 1420608) > +++ subversion/libsvn_fs/fs-loader.c (working copy) > @@ -100,8 +100,8 @@ > const char *funcname; > apr_status_t status; > > -libname = apr_psprintf(pool, "libsvn_fs_%s-%d.so.0", > - name, SVN_VER_MAJOR); > +libname = apr_psprintf(pool, "libsvn_fs_%s-%d.so.%d", > + name, SVN_VER_MAJOR, SVN_SOVERSION); > funcname = apr_psprintf(pool, "svn_fs_%s__init", name); > > /* Find/load the specified library. If we get an error, assume > Index: subversion/libsvn_ra/ra_loader.c > === > --- subversion/libsvn_ra/ra_loader.c (revision 1420608) > +++ subversion/libsvn_ra/ra_loader.c (working copy) > @@ -159,8 +159,8 @@ > const char *compat_funcname; > apr_status_t status; > > -libname = apr_psprintf(pool, "libsvn_ra_%s-%d.so.0", > - ra_name, SVN_VER_MAJOR); > +libname = apr_psprintf(pool, "libsvn_ra_%s-%d.so.%d", > + ra_name, SVN_VER_MAJOR, SVN_SOVERSION); > funcname = apr_psprintf(pool, "svn_ra_%s__init", ra_name); > compat_funcname = apr_psprintf(pool, "svn_ra_%s_init", ra_name); > > Index: subversion/libsvn_subr/auth.c > === > --- subversion/libsvn_subr/auth.c (revision 1420608) > +++ subversion/libsvn_subr/auth.c (working copy) > @@ -399,9 +399,9 @@ >const char *library_label, *library_name; >const char *provider_function_name, *version_function_name; >library_name = apr_psprintf(pool, > - "libsvn_auth_%s-%d.so.0", > + "libsvn_auth_%s-%d.so.%d", >provider_name, > - SVN_VER_MAJOR); > + SVN_VER_MAJOR, SVN_SOVERSION); >library_label = apr_psprintf(pool, "svn_%s", provider_name); >provider_function_name = apr_psprintf(pool, > "svn_auth_get_%s_%s_provider", >
Re: mod_dav_svn assert on root location
I have recompiled with the patch,
When trying to commit to the slave, the client receive:
"Commit failed (details follow):
Server sent unexpected return value (500 Internal Server Error) in response to
MKACTIVITY request for '/!svn/act/12aad366-69cf-2b48-9303-bfb1220af919'
And now the error is logged in the VirtualHost error log (as defined)
instead of the main apache error log.
[Wed Dec 12 16:47:33 2012] [error] [client 10.0.2.15] (125009)APR does
not understand this error code: Invalid URI segment
'!svn/act/779db2c6-6390-e147-a8be-cc8434b0919f' in slave fixup
As i understand it will be best to switch from using root dir to
something like "/svn".
Thanks for your help.
On Wed, Dec 12, 2012 at 3:55 PM, Daniel Shahaf wrote:
> Erez Zarum wrote on Wed, Dec 12, 2012 at 15:33:08 +0200:
>> I am trying to create a master slave configuration with proxy requests
>> through the slave, i have used this configuration on the slave:
>>
>> DAV svn
>> SVNPath /scratch/repo
>>
>> SVNMasterURI"http://master.server.com/svn";
>> ...
>>
>>
>> In 1.7.7 the SVNMasterURI won't let me use http://master.server.com/
>> in 1.6.19 it will.
>> But when i use i get the following assert in the apache
>> error_log (the main log): "httpd: subversion/mod_dav_svn/mirror.c:47:
>> proxy_request_fixup: Assertion `(uri_segment[0] == '\0') ||
>> (uri_segment[0] == '/')' failed."
>> If i use then everything works as expected.
>>
>> Thanks,
>> Erez
>
> Hi :)
>
> Thanks for the due diligent report on IRC, it was helpful.
>
> This should at least fix the assertion (compiled, but untested):
>
> [[[
> Index: subversion/mod_dav_svn/mirror.c
> ===
> --- subversion/mod_dav_svn/mirror.c (revision 1420650)
> +++ subversion/mod_dav_svn/mirror.c (working copy)
> @@ -39,12 +39,17 @@
> URI_SEGMENT is the URI bits relative to the repository root (but if
> non-empty, *does* have a leading slash delimiter).
> MASTER_URI and URI_SEGMENT are not URI-encoded. */
> -static void proxy_request_fixup(request_rec *r,
> -const char *master_uri,
> -const char *uri_segment)
> +static int proxy_request_fixup(request_rec *r,
> + const char *master_uri,
> + const char *uri_segment)
> {
> -assert((uri_segment[0] == '\0')
> - || (uri_segment[0] == '/'));
> +if (uri_segment[0] != '\0' && uri_segment[0] != '/')
> + {
> +ap_log_rerror(APLOG_MARK, APLOG_ERR, SVN_ERR_BAD_CONFIG_VALUE, r,
> + "Invalid URI segment '%s' in slave fixup",
> + uri_segment);
> +return HTTP_INTERNAL_SERVER_ERROR;
> + }
>
> r->proxyreq = PROXYREQ_REVERSE;
> r->uri = r->unparsed_uri;
> @@ -67,6 +72,7 @@
> ap_add_output_filter("LocationRewrite", NULL, r, r->connection);
> ap_add_output_filter("ReposRewrite", NULL, r, r->connection);
> ap_add_input_filter("IncomingRewrite", NULL, r, r->connection);
> +return OK;
> }
>
>
> @@ -101,8 +107,10 @@ int dav_svn__proxy_request_fixup(request_rec *r)
> "/txn/", (char *)NULL))
> || ap_strstr_c(seg, apr_pstrcat(r->pool, special_uri,
> "/txr/", (char *)NULL)))
> {
> +int rv;
> seg += strlen(root_dir);
> -proxy_request_fixup(r, master_uri, seg);
> +rv = proxy_request_fixup(r, master_uri, seg);
> +if (rv) return rv;
> }
> }
> return OK;
> @@ -116,8 +124,10 @@ int dav_svn__proxy_request_fixup(request_rec *r)
> r->method_number == M_LOCK ||
> r->method_number == M_UNLOCK ||
> ap_strstr_c(seg, special_uri))) {
> +int rv;
> seg += strlen(root_dir);
> -proxy_request_fixup(r, master_uri, seg);
> +rv = proxy_request_fixup(r, master_uri, seg);
> +if (rv) return rv;
> return OK;
> }
> }
> ]]]
>
> I think the actual problem is that root_dir is "/", so after skipping
> strlen(root_dir) bytes the result doesn't start with a slash. We could
> fix that by using svn_uri__skip_ancestor()... but we already don't allow
> SVNMasterURI to be a http://host:port/ URL (i.e., lacking /path
> componets after the root), so maybe we shouldn't bother to try
> supporting root_dir == "/" here.
>
> Thoughts?
>
> Daniel
Re: mod_dav_svn assert on root location
Erez Zarum writes: > I am trying to create a master slave configuration with proxy requests > through the slave, i have used this configuration on the slave: > > DAV svn > SVNPath /scratch/repo > > SVNMasterURI"http://master.server.com/svn"; > ... > > > In 1.7.7 the SVNMasterURI won't let me use http://master.server.com/ > in 1.6.19 it will. That was a deliberate change in r1064734. I'm not sure what went wrong with that setup but the log message is: Disallow attempts to proxy to the server root of a master server. It really just doesn't pan out well when you do. > But when i use i get the following assert in the apache > error_log (the main log): "httpd: subversion/mod_dav_svn/mirror.c:47: > proxy_request_fixup: Assertion `(uri_segment[0] == '\0') || > (uri_segment[0] == '/')' failed." > If i use then everything works as expected. I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4272 for the assert. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: mod_dav_svn assert on root location
Erez Zarum wrote on Wed, Dec 12, 2012 at 15:33:08 +0200:
> I am trying to create a master slave configuration with proxy requests
> through the slave, i have used this configuration on the slave:
>
> DAV svn
> SVNPath /scratch/repo
>
> SVNMasterURI"http://master.server.com/svn";
> ...
>
>
> In 1.7.7 the SVNMasterURI won't let me use http://master.server.com/
> in 1.6.19 it will.
> But when i use i get the following assert in the apache
> error_log (the main log): "httpd: subversion/mod_dav_svn/mirror.c:47:
> proxy_request_fixup: Assertion `(uri_segment[0] == '\0') ||
> (uri_segment[0] == '/')' failed."
> If i use then everything works as expected.
>
> Thanks,
> Erez
Hi :)
Thanks for the due diligent report on IRC, it was helpful.
This should at least fix the assertion (compiled, but untested):
[[[
Index: subversion/mod_dav_svn/mirror.c
===
--- subversion/mod_dav_svn/mirror.c (revision 1420650)
+++ subversion/mod_dav_svn/mirror.c (working copy)
@@ -39,12 +39,17 @@
URI_SEGMENT is the URI bits relative to the repository root (but if
non-empty, *does* have a leading slash delimiter).
MASTER_URI and URI_SEGMENT are not URI-encoded. */
-static void proxy_request_fixup(request_rec *r,
-const char *master_uri,
-const char *uri_segment)
+static int proxy_request_fixup(request_rec *r,
+ const char *master_uri,
+ const char *uri_segment)
{
-assert((uri_segment[0] == '\0')
- || (uri_segment[0] == '/'));
+if (uri_segment[0] != '\0' && uri_segment[0] != '/')
+ {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, SVN_ERR_BAD_CONFIG_VALUE, r,
+ "Invalid URI segment '%s' in slave fixup",
+ uri_segment);
+return HTTP_INTERNAL_SERVER_ERROR;
+ }
r->proxyreq = PROXYREQ_REVERSE;
r->uri = r->unparsed_uri;
@@ -67,6 +72,7 @@
ap_add_output_filter("LocationRewrite", NULL, r, r->connection);
ap_add_output_filter("ReposRewrite", NULL, r, r->connection);
ap_add_input_filter("IncomingRewrite", NULL, r, r->connection);
+return OK;
}
@@ -101,8 +107,10 @@ int dav_svn__proxy_request_fixup(request_rec *r)
"/txn/", (char *)NULL))
|| ap_strstr_c(seg, apr_pstrcat(r->pool, special_uri,
"/txr/", (char *)NULL))) {
+int rv;
seg += strlen(root_dir);
-proxy_request_fixup(r, master_uri, seg);
+rv = proxy_request_fixup(r, master_uri, seg);
+if (rv) return rv;
}
}
return OK;
@@ -116,8 +124,10 @@ int dav_svn__proxy_request_fixup(request_rec *r)
r->method_number == M_LOCK ||
r->method_number == M_UNLOCK ||
ap_strstr_c(seg, special_uri))) {
+int rv;
seg += strlen(root_dir);
-proxy_request_fixup(r, master_uri, seg);
+rv = proxy_request_fixup(r, master_uri, seg);
+if (rv) return rv;
return OK;
}
}
]]]
I think the actual problem is that root_dir is "/", so after skipping
strlen(root_dir) bytes the result doesn't start with a slash. We could
fix that by using svn_uri__skip_ancestor()... but we already don't allow
SVNMasterURI to be a http://host:port/ URL (i.e., lacking /path
componets after the root), so maybe we shouldn't bother to try
supporting root_dir == "/" here.
Thoughts?
Daniel
mod_dav_svn assert on root location
I am trying to create a master slave configuration with proxy requests through the slave, i have used this configuration on the slave: DAV svn SVNPath /scratch/repo SVNMasterURI"http://master.server.com/svn"; ... In 1.7.7 the SVNMasterURI won't let me use http://master.server.com/ in 1.6.19 it will. But when i use i get the following assert in the apache error_log (the main log): "httpd: subversion/mod_dav_svn/mirror.c:47: proxy_request_fixup: Assertion `(uri_segment[0] == '\0') || (uri_segment[0] == '/')' failed." If i use then everything works as expected. Thanks, Erez
Re: svn commit: r1417926 - in /subversion/trunk/subversion/libsvn_wc: externals.c merge.c props.c props.h update_editor.c
julianf...@apache.org writes: > Author: julianfoad > Date: Thu Dec 6 14:58:31 2012 > New Revision: 1417926 > > URL: http://svn.apache.org/viewvc?rev=1417926&view=rev > Log: > Remove the 'base_merge' parameter from svn_wc__merge_props(), instead > doing a 'base merge' iff the 'new_pristine_props' output parameter is given, > for simplicity. > --- subversion/trunk/subversion/libsvn_wc/props.c (original) > +++ subversion/trunk/subversion/libsvn_wc/props.c Thu Dec 6 14:58:31 2012 > @@ -294,12 +294,13 @@ svn_wc__perform_props_merge(svn_wc_notif >/* Note that while this routine does the "real" work, it's only > prepping tempfiles and writing log commands. */ >SVN_ERR(svn_wc__merge_props(&conflict_skel, state, > - &new_pristine_props, &new_actual_props, > + base_merge ? &new_pristine_props : NULL, > + &new_actual_props, I think this change is causing this error: W: ==32246== Conditional jump or move depends on uninitialised value(s) W: ==32246==at 0x510A7F4: svn_wc__perform_props_merge (props.c:340) W: ==32246==by 0x510AA4C: svn_wc_merge_props3 (props.c:392) W: ==32246==by 0x4E73748: merge_dir_props_changed (merge.c:1445) W: ==32246==by 0x4E9B7C5: close_directory (repos_diff.c:1120) W: ==32246==by 0x559EB6D: close_directory (cancel.c:261) W: ==32246==by 0x559EB6D: close_directory (cancel.c:261) W: ==32246==by 0x688FA75: drive (reporter.c:1395) W: ==32246==by 0x688FD9F: finish_report (reporter.c:1451) W: ==32246==by 0x68901C6: svn_repos_finish_report (reporter.c:1543) W: ==32246==by 0x665FEA8: reporter_finish_report (ra_plugin.c:251) W: ==32246==by 0x4E7ACFF: drive_merge_report_editor (merge.c:5320) W: ==32246==by 0x4E81570: do_mergeinfo_aware_dir_merge (merge.c:8901) which is causing the ubuntu buildbot to fail: svn: E235000: In file 'subversion/libsvn_wc/props.c' line 341: assertion failed (new_pristine_props != NULL && new_actual_props != NULL) -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: 1.7.8 up for testing/signing
Philip Herron writes: > Which patch are you referring in paticular? subversion-1.7.5/debian/patches/apr-abi1 subversion-1.7.5/debian/patches/apr-abi2 Index: configure.ac === --- configure.ac(revision 1420608) +++ configure.ac(working copy) @@ -99,19 +99,26 @@ if test `expr $apr_version : 2` -ne 0; then dnl Bump the library so-version to 2 if using APR-2 dnl (Debian uses so-version 1 for APR-1-with-largefile) - SVN_LT_SOVERSION="-version-info 2" + svn_lib_ver=2 dnl APR-2 provides APRUTIL apu_config=$apr_config AC_SUBST(SVN_APRUTIL_INCLUDES) AC_SUBST(SVN_APRUTIL_CONFIG, ["$apu_config"]) AC_SUBST(SVN_APRUTIL_LIBS) AC_SUBST(SVN_APRUTIL_PREFIX) +elif test `expr $apr_version : 1` -ne 0; then + svn_lib_ver=1 + APU_VER_REGEXES=["1\."] + SVN_LIB_APRUTIL($APU_VER_REGEXES) else - SVN_LT_SOVERSION="-version-info 0" - APU_VER_REGEXES=["0\.9\.[7-9] 0\.9\.1[0-9] 1\."] + svn_lib_ver=0 + APU_VER_REGEXES=["0\.9\.[7-9] 0\.9\.1[0-9]"] SVN_LIB_APRUTIL($APU_VER_REGEXES) fi +SVN_LT_SOVERSION="-version-info $svn_lib_ver" AC_SUBST(SVN_LT_SOVERSION) +AC_DEFINE_UNQUOTED(SVN_SOVERSION, $svn_lib_ver, + [Subversion library major verson]) dnl Search for pkg-config AC_PATH_PROG(PKG_CONFIG, pkg-config) Index: subversion/libsvn_fs/fs-loader.c === --- subversion/libsvn_fs/fs-loader.c(revision 1420608) +++ subversion/libsvn_fs/fs-loader.c(working copy) @@ -100,8 +100,8 @@ const char *funcname; apr_status_t status; -libname = apr_psprintf(pool, "libsvn_fs_%s-%d.so.0", - name, SVN_VER_MAJOR); +libname = apr_psprintf(pool, "libsvn_fs_%s-%d.so.%d", + name, SVN_VER_MAJOR, SVN_SOVERSION); funcname = apr_psprintf(pool, "svn_fs_%s__init", name); /* Find/load the specified library. If we get an error, assume Index: subversion/libsvn_ra/ra_loader.c === --- subversion/libsvn_ra/ra_loader.c(revision 1420608) +++ subversion/libsvn_ra/ra_loader.c(working copy) @@ -159,8 +159,8 @@ const char *compat_funcname; apr_status_t status; -libname = apr_psprintf(pool, "libsvn_ra_%s-%d.so.0", - ra_name, SVN_VER_MAJOR); +libname = apr_psprintf(pool, "libsvn_ra_%s-%d.so.%d", + ra_name, SVN_VER_MAJOR, SVN_SOVERSION); funcname = apr_psprintf(pool, "svn_ra_%s__init", ra_name); compat_funcname = apr_psprintf(pool, "svn_ra_%s_init", ra_name); Index: subversion/libsvn_subr/auth.c === --- subversion/libsvn_subr/auth.c (revision 1420608) +++ subversion/libsvn_subr/auth.c (working copy) @@ -399,9 +399,9 @@ const char *library_label, *library_name; const char *provider_function_name, *version_function_name; library_name = apr_psprintf(pool, - "libsvn_auth_%s-%d.so.0", + "libsvn_auth_%s-%d.so.%d", provider_name, - SVN_VER_MAJOR); + SVN_VER_MAJOR, SVN_SOVERSION); library_label = apr_psprintf(pool, "svn_%s", provider_name); provider_function_name = apr_psprintf(pool, "svn_auth_get_%s_%s_provider", -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1420404 - in /subversion/trunk/subversion/libsvn_wc: token-map.h wc-queries.sql
Julian Foad writes:
>> Author: philip
>
>>
>> URL: http://svn.apache.org/viewvc?rev=1420404&view=rev
>> Log:
>> * subversion/libsvn_wc/token-map.h
>> (depth_map): Add some annotations.
>>
>> * subversion/libsvn_wc/wc-queries.sql
>> (STMT_HAS_SPARSE_NODES): Use annotations.
>
>> Modified: subversion/trunk/subversion/libsvn_wc/token-map.h
>> /* The subset of svn_depth_t used in the database. */
>> static const svn_token_map_t depth_map[] = {
>> - { "unknown", svn_depth_unknown },
>> + { "unknown", svn_depth_unknown }, /* MAP_DEPTH_UNKNOWN */
>> { "empty", svn_depth_empty },
>> { "files", svn_depth_files },
>> { "immediates", svn_depth_immediates },
>> - { "infinity", svn_depth_infinity },
>> + { "infinity", svn_depth_infinity }, /* MAP_DEPTH_INFINITY */
>
> Might as well just annotate all the values at once, no?
Perhaps, but I decided to avoid adding things that would be unused.
It's simple enough to add them when needed.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn commit: r1420477 - in /subversion/trunk: build.conf subversion/tests/libsvn_ra/ subversion/tests/libsvn_ra/ra-test.c
Daniel Shahaf wrote on Wed, Dec 12, 2012 at 13:21:07 +0200: > julianf...@apache.org wrote on Tue, Dec 11, 2012 at 22:42:55 -: > > +[ra-test] > > +description = Test a few things in libsvn_ra > > +type = exe > > +path = subversion/tests/libsvn_ra > > +sources = ra-test.c > > +install = test > > +libs = libsvn_test libsvn_ra libsvn_fs libsvn_delta libsvn_subr > > + apriconv apr neon > > Neon? Ignore me, it's been fixed already.
Re: svn commit: r1420477 - in /subversion/trunk: build.conf subversion/tests/libsvn_ra/ subversion/tests/libsvn_ra/ra-test.c
julianf...@apache.org wrote on Tue, Dec 11, 2012 at 22:42:55 -: > +[ra-test] > +description = Test a few things in libsvn_ra > +type = exe > +path = subversion/tests/libsvn_ra > +sources = ra-test.c > +install = test > +libs = libsvn_test libsvn_ra libsvn_fs libsvn_delta libsvn_subr > + apriconv apr neon Neon?
Re: 1.7.8 up for testing/signing
On 11/12/12 16:11, Peter Samuelson wrote: > > [Philip Martin] >> I assume WANdisco's package is intended to replace the libraries in the >> standard Debian or Ubuntu libsvn1 package, in which case you need to use >> the same patch. If you ship -1.so.0 libraries then applications linked >> to the -1.so.1 libraries will fail to start. > > Well, they'll fail to start _if_ your package is actually named > 'libsvn1' and thus replaces the system libsvn1. Calling a package > 'libsvn1' implies that you intend to ship libsvn_*-1.so.1. And > certainly the obvious course is to use my ABI patch, but if you'd > rather stay truer to upstream Subversion, just name your library > package something else (we called it libsvn0 before the patch) and the > two packages can happily coexist on a system. Apps compiled for the > one will use the one, apps compiled for the other will use the other. > Which patch are you referring in paticular? I've tried a lot of patches in some debian packages and they don't really work i've got all kinds of errors sometimes only on 64bit not being able to find some svn change path function isn't being compiled, and sometimes the patches dont apply. And is it really that big a deal? Chaning it from 0 to 1. Abi change etc, its still only a name of a library. I have debian packages for and they work for us upgrading from the default subversion system: debian 5 32/64 debain 6 32/64 ubuntu 1004 32/64 ubuntu 1204 32/64 And i needed to repackages serf on ubuntu 1204 since it generates the broken dependency of libserf-private which doesn't exist. Maybe if i could see the single patch that refers to this i can apply it or i can push to make a libsvn0 might be a good idea but that might break git-svn or something since it depends libsvn1 maybe not since they both can exist and libsvn1 will always be default systems libsvn. On rhel 5/6 the libaries are left as is 0. Why isn't it a problem there.
