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 4:24 PM, C. Michael Pilato cmpil...@collab.netwrote: 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. Both approaches (allow config option to control # of conns; have svnrdump disable parallelism) seems reasonable to me. FWIW, I'd probably set it to 8 - since 2006, most browsers upped their connection parallelism to 8. *grin* And, yah, it's quite obvious from reading the thread that you missed a bunch of Lieven's emails. -- justin
Re: [PATCH] Test for line ending bug in svnrdump (issue 4263)
On Wed, Dec 12, 2012 at 5:06 PM, Daniel Shahaf danie...@elego.de wrote: P.S. This thread was an unusually long one, for a patch that adds about a dozen lines of code. Uh, how is that at all unusual for this crowd? =) -- justin
Re: mod_dav_svn assert on root location
Philip Martin wrote on Wed, Dec 12, 2012 at 14:13:34 +: Erez Zarum erezza...@gmail.com writes: I am trying to create a master slave configuration with proxy requests through the slave, i have used this configuration on the slave: Location / DAV svn SVNPath /scratch/repo SVNMasterURIhttp://master.server.com/svn; ... /Location 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 Location / 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 Location /url then everything works as expected. I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4272 for the assert. Do you plan to work on this, or should I apply the patch I posted elsethread? Even if it's not the best fix it does resolve an assertion, so we could apply it now and look at further improvements later.
Re: mod_dav_svn assert on root location
Daniel Shahaf danie...@elego.de writes: Do you plan to work on this, or should I apply the patch I posted elsethread? I'm not working on it. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: 1.7.8 up for testing/signing
Summary: +1 to release Platform: Linux (Debian/wheezy) Tested: (local, svn, svn+sasl, serf, neon) x (fsfs, fsfs/pack/shard, bdb) (serf/v1, neon/v1) x (fsfs, bdb) swig-pl, swig-py, swig-rb javahl x (fsfs, bdb) Results: All tests PASS Local dependencies: apache2-threaded-dev : 2.2.22-12 libapr1-dev : 1.4.6-3 libaprutil1-dev : 1.4.1-3 libdb5.1-dev : 5.1.29-5 libneon27-dev : 0.29.6-3 libsasl2-dev : 2.1.25.dfsg1-6 libsqlite3-dev : 3.7.13-1 perl : 5.14.2-15 python2.7-dev : 2.7.3~rc2-2.1 ruby1.8-dev : 1.8.7.358-6 openjdk-7-jdk : 7u3-2.1.3-1 serf : 1.2.x@1706 subversion-1.7.8.tar.bz2.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABCAAGBQJQycFrAAoJEHbXiOHtGlmc6t8H/35ONmj+k48E1CnUR5g45uPI 7knYIonyz6YY/cG1jKmEkUI25AdZW48Abc+DxQiZO/nImfj+V4iviWQjRF9h3e1i cR1ccbYGTO6n8O+yE4h4Ma0Am+Sam6eVRtm4BoBBngLmb8Sl9chBe2uWd91Ec8oo 4E80LtIFewcVQNaAbrwwnELTnbIty/m059DAr4OXBJhjbewLiXkwKSj06WCqFXoE wnhH/TMS+JHDYnmGIfqVi6oDWGRUhXMaKEf7RK0OqJYlkKovG4v8EmFG+1VUtOP6 ClFRSIjjEEiL/0VDp/v9nfM4KDavCEweK7M8ugiOqfz+PFAweeg9AtDBi1TpUSo= =Onxh -END PGP SIGNATURE- subversion-1.7.8.tar.gz.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABCAAGBQJQycFrAAoJEHbXiOHtGlmcF0MIAKe/MmKEYWjUq6yhoj8s3V+h ro9qVIjvzXZp2NRNa2X7+xmVA4S1KcXo0eCdIJok8E2wWphNOAwk3xa15EToQ0DX V/L5mkKcwanzKYOVBP63fWcmIMmRl8RhdjQnFlu3k8szG3gPysH38WCVszl5JC+2 m8k3IwJgGWMajOO+NvjslCWE5yClExjH/LopotBbst8BmpGwHdCIQzhU1PKYi2R5 c+LK8lsAJvXybAQM/oAm7S8VsyIbWBOO8Jfw0PXhYLZwHYbQevRatJB4mck7ekGH nwDBjV2WSGRa+v+4204hE355Nz1jXzV4QsKenUMv4+balQllX9bAJSTxoVNMbbI= =4vxR -END PGP SIGNATURE- -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
[PATCH] Code refactoring in svn_ra_serf__replay_range()
Hi,
This patch uses an existing function(svn_ra_serf__context_run_wait)
instead of in-line code for processing the connections defined by the
serf context.
Attached the patch and log message.
Thanks Regards,
Vijayaguru
Index: subversion/libsvn_ra_serf/replay.c
===
--- subversion/libsvn_ra_serf/replay.c (revision 1421076)
+++ subversion/libsvn_ra_serf/replay.c (working copy)
@@ -698,8 +698,8 @@
* optimally. Originally we used 5 as the max. number of outstanding
* requests, but this turned out to be too low.
*
- * Serf doesn't exit out of the serf_context_run loop as long as it
- * has data to send or receive. With small responses (revs of a few
+ * Serf doesn't exit out of the svn_ra_serf__context_run_wait loop as long as
+ * it has data to send or receive. With small responses (revs of a few
* kB), serf doesn't come out of this loop at all. So with
* MAX_OUTSTANDING_REQUESTS set to a low number, there's a big chance
* that serf handles those requests completely in its internal loop,
@@ -732,14 +732,11 @@
svn_revnum_t rev = start_revision;
const char *report_target;
int active_reports = 0;
- apr_interval_time_t waittime_left = session-timeout;
SVN_ERR(svn_ra_serf__report_resource(report_target, session, NULL, pool));
while (active_reports || rev = end_revision)
{
- apr_status_t status;
- svn_error_t *err;
svn_ra_serf__list_t *done_list;
svn_ra_serf__list_t *done_reports = NULL;
replay_context_t *replay_ctx;
@@ -856,41 +853,9 @@
### ahead and apply it here, too, in case serf eventually uses
### that parameter.
*/
- status = serf_context_run(session-context,
-SVN_RA_SERF__CONTEXT_RUN_DURATION,
-pool);
- err = session-pending_error;
- session-pending_error = NULL;
+ SVN_ERR(svn_ra_serf__context_run_wait(replay_ctx-done, session, pool));
- /* If the context duration timeout is up, we'll subtract that
- duration from the total time alloted for such things. If
- there's no time left, we fail with a message indicating that
- the connection timed out. */
- if (APR_STATUS_IS_TIMEUP(status))
-{
- svn_error_clear(err);
- err = SVN_NO_ERROR;
- status = 0;
-
- if (session-timeout)
-{
- if (waittime_left SVN_RA_SERF__CONTEXT_RUN_DURATION)
-{
- waittime_left -= SVN_RA_SERF__CONTEXT_RUN_DURATION;
-}
- else
-{
- return svn_error_create(SVN_ERR_RA_DAV_CONN_TIMEOUT, NULL,
- _(Connection timed out));
-}
-}
-}
- else
-{
- waittime_left = session-timeout;
-}
-
/* Substract the number of completely handled responses from our
total nr. of open requests', so we'll know when to stop this loop.
Since the message is completely handled, we can destroy its pool. */
@@ -904,12 +869,6 @@
active_reports--;
}
- SVN_ERR(err);
- if (status)
-{
- return svn_ra_serf__wrap_err(status,
- _(Error retrieving replay REPORT));
-}
done_reports = NULL;
}
Use an existing API(svn_ra_serf__context_run_wait()) instead of in-line code for
processing connections defined by the serf context.
* subversion/libsvn_ra_serf/replay.c
(svn_ra_serf__replay_range): As above.
Patch by: Vijayaguru G vijay{_AT_}collab.net
Re: [PATCH] Code refactoring in svn_ra_serf__replay_range()
On 12/13/2012 09:53 AM, vijay wrote: Hi, This patch uses an existing function(svn_ra_serf__context_run_wait) instead of in-line code for processing the connections defined by the serf context. Attached the patch and log message. Looks good. I did some additional cleanup of comments made stale by the change, and committed as r 1421369. Thanks! -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
RFC: Build system changes
The attached patch makes several changes to how we discover compilers
and set flags on *nix:
* Search for clang as well as the default gcc/cc, and prefer clang(++)
over gcc/g++.
* Set standards-compliance mode (C90/C++11) even without maintainer-mode.
* Add -pipe to C(XX)FLAGS if the compiler supports it. This speeds up
compilation a bit in my tests.
I tested this on Mac OS (with clang) and Linux (without clang) but don't
know how it affects bindings.
Please review.
-- Brane
{{{
* build/ac-macros/compiler.m4: New file.
(SVN_PROG_CC, SVN_CFLAGS_ADD_IFELSE,
SVN_PROG_CXX, SVN_CXXFLAGS_ADD_IFELSE): New.
* aclocal.m4: Include build/ac-macros/compiler.m4.
* configure.ac:
- Use SVN_PROG_CC instead of AC_PROG_CC
- Use SVN_PROG_CXX instead of AC_PROG_CXX
- Use SVN_CFLAGS_ADD_IFELSE and SVN_CXXFLAGS_ADD_IFELSE
to add mainter-mode flags
- Do not remove -ansi for clang, since it's not set any more.
}}}
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Index: aclocal.m4
===
--- aclocal.m4 (revision 1421399)
+++ aclocal.m4 (working copy)
@@ -36,6 +36,7 @@
sinclude(build/ac-macros/aprutil.m4)
sinclude(build/ac-macros/apr_memcache.m4)
sinclude(build/ac-macros/berkeley-db.m4)
+sinclude(build/ac-macros/compiler.m4)
sinclude(build/ac-macros/ctypesgen.m4)
sinclude(build/ac-macros/gssapi.m4)
sinclude(build/ac-macros/java.m4)
Index: configure.ac
===
--- configure.ac(revision 1421399)
+++ configure.ac(working copy)
@@ -48,12 +48,10 @@
# Check for programs
-# Look for a C compiler (before anything can set CFLAGS)
-AC_PROG_CC
+# Look for a C and C++ compiler (before anything can set CFLAGS or CXXFLAGS)
+SVN_PROG_CC
+SVN_PROG_CXX
-# Look for a C++ compiler
-AC_PROG_CXX
-
# Look for a C pre-processor
AC_PROG_CPP
@@ -990,62 +988,31 @@
AC_MSG_NOTICE([maintainer-mode: adding GCC warning flags])
dnl Enable some extra warnings. Put these before the user's flags
dnl so the user can specify flags that override these.
-CFLAGS=-Wpointer-arith -Wwrite-strings -Wshadow -ansi -Wall
-Wformat=2 -Wunused -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wno-multichar -Wredundant-decls -Wnested-externs
-Wunreachable-code -Winline -Wno-long-long $CFLAGS
-CXXFLAGS=-Wpointer-arith -Wwrite-strings -Wshadow -ansi -Wall
$CXXFLAGS
+dnl Add each of the following flags only if the C compiler accepts it.
+SVN_CFLAGS_ADD_IFELSE([-Werror=declaration-after-statement])
+SVN_CFLAGS_ADD_IFELSE([-Wextra-tokens])
+SVN_CFLAGS_ADD_IFELSE([-Wnewline-eof])
+SVN_CFLAGS_ADD_IFELSE([-Wshorten-64-to-32])
+SVN_CFLAGS_ADD_IFELSE([-Wold-style-definition])
+SVN_CFLAGS_ADD_IFELSE([-Wno-format-nonliteral])
+SVN_CFLAGS_ADD_IFELSE([-Wno-system-headers])
+
+dnl Add each of the following flags only if the C++ compiler accepts
it.
+SVN_CXXFLAGS_ADD_IFELSE([-Wextra-tokens])
+SVN_CXXFLAGS_ADD_IFELSE([-Wshorten-64-to-32])
+SVN_CXXFLAGS_ADD_IFELSE([-Wno-system-headers])
+
+dnl Finally, prepend a standard set of extra warnings that
+dnl even very old compilers understand
+CFLAGS=-Wpointer-arith -Wwrite-strings -Wshadow -Wall -Wformat=2
-Wunused -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wno-multichar -Wredundant-decls -Wnested-externs
-Wunreachable-code -Winline -Wno-long-long $CFLAGS
+CXXFLAGS=-Wpointer-arith -Wwrite-strings -Wshadow -Wall $CXXFLAGS
+
dnl some additional flags that can be handy for an occasional review,
dnl but throw too many warnings in svn code, of too little importance,
dnl to keep these enabled. Remove the dnl to do a run with these
dnl switches enabled.
dnl CFLAGS=-Wswitch-enum -Wswitch-default $CFLAGS
-
-dnl Add each of the following flags only if the C compiler accepts it.
-
-CFLAGS_KEEP=$CFLAGS
-AC_LANG_PUSH([C])
-
-CFLAGS=-Werror=declaration-after-statement $CFLAGS_KEEP
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP=$CFLAGS])
-
-CFLAGS=-Wextra-tokens $CFLAGS_KEEP
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP=$CFLAGS])
-
-CFLAGS=-Wnewline-eof $CFLAGS_KEEP
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP=$CFLAGS])
-
-CFLAGS=-Wshorten-64-to-32 $CFLAGS_KEEP
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP=$CFLAGS])
-
-CFLAGS=-Wold-style-definition $CFLAGS_KEEP
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP=$CFLAGS])
-
-CFLAGS=-Wno-system-headers $CFLAGS_KEEP
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP=$CFLAGS])
-
-
Re: RFC: Build system changes
Branko Čibej br...@wandisco.com writes:
{{{
* build/ac-macros/compiler.m4: New file.
(SVN_PROG_CC, SVN_CFLAGS_ADD_IFELSE,
SVN_PROG_CXX, SVN_CXXFLAGS_ADD_IFELSE): New.
* aclocal.m4: Include build/ac-macros/compiler.m4.
* configure.ac:
- Use SVN_PROG_CC instead of AC_PROG_CC
- Use SVN_PROG_CXX instead of AC_PROG_CXX
- Use SVN_CFLAGS_ADD_IFELSE and SVN_CXXFLAGS_ADD_IFELSE
to add mainter-mode flags
- Do not remove -ansi for clang, since it's not set any more.
}}}
When running autogen.sh I get:
configure.ac:52: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was
required
configure.ac:52:
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required
../../lib/autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
../../lib/autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
build/ac-macros/compiler.m4:33: _SVN_XXFLAGS_ADD_IFELSE is expanded from...
build/ac-macros/compiler.m4:50: SVN_CFLAGS_ADD_IFELSE is expanded from...
build/ac-macros/compiler.m4:57: SVN_PROG_CC is expanded from...
configure.ac:52: the top level
and similar for AC_PROG_CXX, both repeated with different line numbers.
Linking fails:
cd subversion/libsvn_subr /bin/bash /home/pm/sw/subversion/obj/libtool
--tag=CC --silent --mode=link gcc -shared -std=c90 -pipe -pthread
-Werror=implicit-function-declaration -DSVN_DEBUG -DAP_DEBUG -rpath
/usr/local/subversionx/lib -version-info 0 -o libsvn_subr-1.la adler32.lo
atomic.lo auth.lo base64.lo cache-inprocess.lo cache-membuffer.lo
cache-memcache.lo cache.lo cache_config.lo checksum.lo cmdline.lo compat.lo
config.lo config_auth.lo config_file.lo config_win.lo crypto.lo ctype.lo
date.lo debug.lo deprecated.lo dirent_uri.lo dso.lo eol.lo error.lo
gpg_agent.lo hash.lo io.lo iter.lo lock.lo log.lo macos_keychain.lo magic.lo
md5.lo mergeinfo.lo mutex.lo named_atomic.lo nls.lo opt.lo path.lo pool.lo
prompt.lo properties.lo pseudo_md5.lo quoprint.lo sha1.lo simple_providers.lo
skel.lo sorts.lo spillbuf.lo sqlite.lo sqlite3wrapper.lo
ssl_client_cert_providers.lo ssl_client_cert_pw_providers.lo
ssl_server_trust_providers.lo stream.lo string.lo subst.lo sysinfo.lo target.lo
temp_serializer.lo time.lo token.lo types.lo user.lo username_providers.lo
utf.lo utf_validate.lo utf_width.lo validate.lo version.lo win32_crashrpt.lo
win32_crypto.lo win32_xlate.lo xml.lo -laprutil-1 -lapr-1 -lexpat -lz
-lsqlite3 -lmagic
gcc: error: unrecognized command line option '-soname'
gcc: error: libsvn_subr-1.so.0: No such file or directory
make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1
--
Certified Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: RFC: Build system changes
* Search for clang as well as the default gcc/cc, and prefer clang(++) over gcc/g++. Is clang considered superior, then? Fair enough, I haven't really kept up. * Add -pipe to C(XX)FLAGS if the compiler supports it. This speeds up compilation a bit in my tests. Hmm. It seems very strange to me that the compiler driver cannot already auto-select the most efficient means: pipes, shared memory, temp files, or (in gcc's case) just integrating the preprocessor into the compiler binary directly. And indeed, I thought gcc -pipe had been basically obsolete for many years (still supported, but no faster than the default mode). Is it really faster for you? With what compiler and platform? Perhaps I should test it here. + dnl Try to turn on C++11 mode so that we can use + dnl std::shared_ptr and similar goodies + dnl g++ and clang++ + SVN_CXXFLAGS_ADD_IFELSE([-std=c++11],[],[ +SVN_CXXFLAGS_ADD_IFELSE([-std=c++0x]) + ]) This bit confuses me as well. Does our C++ code now require this mode? If not, what's the use of the flag? Peter
Re: 1.7.8 up for testing/signing
Ben Reser wrote: The 1.7.8 release artifacts are now available for testing/signing. Summary: +1 to release Platform: Linux (Ubuntu 11.10) Tested: [ bdb | fsfs ] x [ ra_local | ra_svn | ra_neon | ra_serf ] swig-py swig-pl swig-rb ctypes-python javahl Results: All tests PASS Dependency versions: libapr1 1.4.5-1 libaprutil1 1.3.12+dfsg-2 libdb-dev 5.1.4 openssl 1.0.0e-2ubuntu4 1.0.0e-2ubuntu4.6 perl 5.12.4-4 5.12.4-4ubuntu0.1 python 2.7.2-7ubuntu2 ruby 1.8.7 (2011-06-30 patchlevel 352) swig 1.3.40 neon 0.29.6 zlib1g 1:1.2.3.4.dfsg-3ubuntu3 ctypesgen trunk@141 Signatures: ::: subversion-1.7.8.tar.bz2 ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlDI6uEACgkQNR8z5DU+JbzK1QCfSoBP39kcVR4JaEP+DaHHNg3f CNQAn3qLiAWI+EkG2FhoC8H2D8LJriKK =Nuit -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJQyf2TAAoJEB+wZLhO7MSTyLkP/iKYzZkSZIwbSIAeon06ekPV Cm+7DcgKKNqozLqLrTT2vf4NBFHqlOdtfdqcHr5fOSDk54FDV2uNejoI3p6qw651 bdSpsEoor+0z6WzajcwTP8ych0MlN2hDOFcyZr2nMRTkdzdC/3Q1NjJVl43s+LSq 6XYadPrmopOIaiG8x3MRfCk0RVqRR6TJsSDFXm/s7uTp95zAeg77OkguvjKx+G6i FXY8QmVC3yBAjkQ4q1/BeM1SgSqwmzhFkcDXuBHgrNqqX2TG1kT5aDWX0c6JHzUr 5RQBh0WOUEBmAL/mVVJKmDeKJe/osDZJJfobZTJmtFIN8YmfqsQAqN1ZwJuP5zPg uq7HFWmL5PZ0d1W00FtnnC3usTN42ihH9P0XhvRH3zlq5nJrRw+zM/J9wVSiXyLz RP0tQ9QILVl6pEmkW0cuoymifbdZnon5mC8NDK1/7fRp+CXU0Pu5KrL8IoIrwPqS LTog2nn4rfuoLEwM2kBPh2xmj0x+FCr/3vaJEqQ0z9oVXZQjxlXUyBO8D+sVxRcl KDmxOjnXzwU2GxrZCvUcfxxbgQNTp/UcWoPb6x+fPAVzqrGPGnxNCC2k3Un8MWOa OMyHJoEtOuGaZzt5ebOqXT7SysGhOsGw2WPeEXfcayl2RJwMikAYf+jXn0bPqQ/C 1NVlNUxNPfU1YJLb2weE =zqet -END PGP SIGNATURE- ::: subversion-1.7.8.tar.gz.asc ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlDI6uIACgkQNR8z5DU+Jbyb9QCcDO8PJDYanZovpAvFX+vW6XGf XUIAnAz0tIsAv6cVX+o1gNwBIzzYYpN6 =jG3J -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJQyf2TAAoJEB+wZLhO7MSTK9sP/0LdC+FRoRloAkqVOet16egs aPg/jIJJB5tLFsX6MGi1KiEo7KLaqQzniqNYpyH7VnqJUZaA5AuptTkqu5KzYKJn Kv931bqe5pH+RleLL1sIOrkyD4HfVNUUjG6dCHaTGLBOTuiKRuGiIRd1J97tzTME WOSWHzflhGuTwnqQnDN2ybgcDnUZniiPRz8r6s2LqlOYF+wFYStWqozdLcuvMmem lEXh2v5Gq8wY6Q6a+NVyd5AvdOSq36+Hg7fsV71DBThasAK6gTXfdARHdwiB8qz8 Ykcp4Ui6mKVgsz6+jUHpT3PzeCZHYFndKqDb9We8NjITEpbwFNSsKZMWwZfkuMfS 2YFsuDXEvq/gkixln8D0pmnI394XINgvC64aMkFyc36rQl+t07KYhO532dKfjZWh 6XTnf5HcgNohGs/pdBkRleM+lItdKuOYrSJE0G7v5DajwfshXi7VdytuDHU64lUF /Qd9iyq2EqFbKHDs48FjuyppfH0hw8ovetqtvBrs0j3b6WjIRo1utOBufp6yhsQM cjnzjyG2CkpF340BGXWV7nHZ2cwgK6drknUWksf8k9g2dXVaeFQr4wP6EuS7fMF9 D2IebraLIvtNW6C+3toQs4dkRcvtjMo5G+1TFvkqduDr667k0Liohw4JU8jshSdD Of9fvLPXg96LrVgwpA0X =fO8M -END PGP SIGNATURE- - Julian -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c
On 12/13/2012 05:48 AM, Justin Erenkrantz wrote: On Wed, Dec 12, 2012 at 4:24 PM, C. Michael Pilato cmpil...@collab.net mailto:cmpil...@collab.net wrote: 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. Both approaches (allow config option to control # of conns; have svnrdump disable parallelism) seems reasonable to me. FWIW, I'd probably set it to 8 - since 2006, most browsers upped their connection parallelism to 8. *grin* Okay. In r1421559 I implemented the http-max-connections option. Defaults to 4. Hard-coded limit of 8. (All that is up for discussion/debate/etc.) But on the way to adding the code to svnrdump to hard-code that configuration option, I found myself wondering ... could we get away with using a hardcoded-into-svnrdump *private* configuration variable that just means, Do whatever you need to ensure that the editor is driven sanely? I realize this is similar to the idea I previously shot down, but the difference here is that I'm not talking about using a user-visible, shows-up-in-the-config-template-file option here. Just a #define and a value stuffed into the configuration hash. Thoughts? -- C. Michael Pilato cmpil...@collab.net 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 Thu, Dec 13, 2012 at 11:06 PM, C. Michael Pilato cmpil...@collab.net wrote: On 12/13/2012 05:48 AM, Justin Erenkrantz wrote: On Wed, Dec 12, 2012 at 4:24 PM, C. Michael Pilato cmpil...@collab.net mailto:cmpil...@collab.net wrote: 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. Both approaches (allow config option to control # of conns; have svnrdump disable parallelism) seems reasonable to me. FWIW, I'd probably set it to 8 - since 2006, most browsers upped their connection parallelism to 8. *grin* Okay. In r1421559 I implemented the http-max-connections option. Defaults to 4. Hard-coded limit of 8. (All that is up for discussion/debate/etc.) But on the way to adding the code to svnrdump to hard-code that configuration option, I found myself wondering ... could we get away with using a hardcoded-into-svnrdump *private* configuration variable that just means, Do whatever you need to ensure that the editor is driven sanely? I realize this is similar to the idea I previously shot down, but the difference here is that I'm not talking about using a user-visible, shows-up-in-the-config-template-file option here. Just a #define and a value stuffed into the configuration hash. Thoughts? I have thought about the same thing before, but I don't think it's a good idea. It will give our applications sort of an extra API that external applications don't have. But an application using the ra API might have the same problem with ra_serf as svnrdump has. IMHO, the option to make ra_serf respect a more stricter interpretation of the editor api is something we need to give to a developer, not to a user via config. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development Lieven
Re: svn commit: r1409652 - /subversion/trunk/subversion/tests/cmdline/patch_tests.py
On Thu, Nov 15, 2012 at 12:40 AM, danie...@apache.org wrote:
Author: danielsh
Date: Thu Nov 15 05:40:40 2012
New Revision: 1409652
URL: http://svn.apache.org/viewvc?rev=1409652view=rev
Log:
Add a skeleton XFail test. There is no issue number yet, but the bug is being
discussed on users@.
Hi Daniel,
Was an issue ever filed for this? More importantly, is it a
regression or does it otherwise block 1.8?
* subversion/tests/cmdline/patch_tests.py
(patch_change_symlink_target): New.
(test_list): Run it.
Modified:
subversion/trunk/subversion/tests/cmdline/patch_tests.py
Modified: subversion/trunk/subversion/tests/cmdline/patch_tests.py
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/patch_tests.py?rev=1409652r1=1409651r2=1409652view=diff
==
--- subversion/trunk/subversion/tests/cmdline/patch_tests.py (original)
+++ subversion/trunk/subversion/tests/cmdline/patch_tests.py Thu Nov 15
05:40:40 2012
@@ -4201,6 +4201,40 @@ def patch_git_with_index_line(sbox):
1, # check-props
1) # dry-run
+@XFail(svntest.main.is_posix_os)
+def patch_change_symlink_target(sbox):
+ patch changes symlink target
+
+ sbox.build()
+ wc_dir = sbox.wc_dir
+ patch_file_path = make_patch_path(sbox)
+ svntest.main.file_write(patch_file_path, '\n'.join([
+Index: link,
+===,
+--- iota(revision 1),
++++ iota(working copy),
+@@ -1 +1 @@,
+-link foo,
+\\ No newline at end of file,
++link bar,
+\\ No newline at end of file,
+,
+]))
+
+ # r2
+ sbox.simple_add_symlink('target', 'link')
+ sbox.simple_commit()
+
+ expected_output = [
+'M %s\n' % sbox.ospath('link'),
+ ]
+
+ # This currently fails.
+ # TODO: when it passes, verify that the on-disk 'link' is correct ---
+ # symlink to 'bar' (or link bar on non-HAVE_SYMLINK platforms)
+ svntest.actions.run_and_verify_svn(None, U *link, [],
+ 'patch', patch_file_path, wc_dir)
+
#Run the tests
@@ -4246,6 +4280,7 @@ test_list = [ None,
patch_target_no_eol_at_eof,
patch_add_and_delete,
patch_git_with_index_line,
+ patch_change_symlink_target,
]
if __name__ == '__main__':
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: 1.8 Progress
On Tue, Nov 6, 2012 at 3:37 PM, Paul Burba ptbu...@gmail.com wrote: On Sat, Nov 3, 2012 at 9:33 AM, Stefan Sperling s...@elego.de wrote: On Fri, Nov 02, 2012 at 06:00:52PM -0400, Paul Burba wrote: These six XFailing upate tests are all part of this effort correct? 61XFAIL update locally moved dir with leaf del 62XFAIL update locally moved dir with edited leaf del 63XFAIL update locally moved dir with incoming file 64XFAIL update locally moved dir with incoming dir I believe the above date back to 1.6. They verify that tree conflict detection works correctly. I might have changed them since 1.7 was branched to account for some changes I made. I'll look into that next week. Ping. You had any chance to take a look at these? -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
1.8 Release Status : Test Review Task
Per the 1.8 Release Status 'Test Review' item on the roadmap, we're in pretty good shape (at least compared to where we were at a similar time for 1.7). Here's where we stand re XFail and WIP tests that need to be fixed before release: Of all the XFailing tests *with* an associated issue, there is currently only a single test, update_tests.py #65, that is a blocker for 1.8, update_tests.py 65 'update locally moved dir with incoming file move', though nobody is assigned to the issue. There are also 23 tests with associated issues which are marked as '1.8-consider'. C:\SVN\src-trunkwin-tests.py --log-level=DEBUG --log-to-stdout --mode-filter=XFAIL --milestone-filter (1.8.*|---) --list --url http://localhost LISTING: basic_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 61XFAIL rm missing item with case-clashing ondisk item #4023(1.8-consider/issues@subversion) LISTING: copy_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 103XFAIL copy and move conflicts #3899(1.8-consider/sbutler) LISTING: diff_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 61XFAIL diff WC-WC shows the correct base rev num #4010(1.8-consider/issues@subversion) LISTING: externals_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 37XFAIL commit --include-externals --depth=immediates #4252(1.8-consider/issues@subversion) 38XFAIL external shadows an existing dir #4085(1.8-consider/issues@subversion) LISTING: merge_automatic_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 18XFAIL reintegrate considers source subtree mergeinfo #4258(1.8-consider/issues@subversion) LISTING: merge_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 49XFAIL avoid repeated merges for cyclic merging #2897(1.8-consider/issues@subversion) 114XFAIL don't inherit bogus mergeinfo #3668(1.8-consider/issues@subversion) #3669(1.8-consider/issues@subversion) 115XFAIL don't inherit bogus working mergeinfo #3756(1.8-consider/issues@subversion) 125XFAIL svnmucc: merge a replacement #4132(1.8-consider/issues@subversion) LISTING: merge_tree_conflict_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 12XFAIL tree conflicts 5.1: leaf edit, tree del #2282(1.8-consider/issues@subversion) 13XFAIL tree conflicts 5.2: leaf del, tree del #2282(1.8-consider/issues@subversion) 18XFAIL tree conflicts 5.2: leaf del (no ci), tree del #2282(1.8-consider/issues@subversion) 24XFAIL merge replace on local delete fails #4011(1.8-consider/issues@subversion) LISTING: prop_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 12XFAIL set, get, and delete a revprop change #3086(1.8-consider/issues@subversion) 26XFAIL test handling invalid svn:* property values #3086(1.8-consider/issues@subversion) LISTING: revert_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 25XFAIL revert a copy with depth=files #3851(1.8-consider/issues@subversion) 26XFAIL revert a nested add with depth=immediates #3851(1.8-consider/issues@subversion) LISTING: switch_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 9XFAIL switch a file to a dir and back to the file #1532(1.8-consider/issues@subversion) LISTING: tree_conflict_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 8XFAIL up/sw dir: add onto add #3314(1.8-consider/issues@subversion) 14XFAIL merge dir: del/rpl/mv onto not-same #3150(1.8-consider/issues@subversion) LISTING: update_tests.py Test # Mode Test Description Issue#(Target Mileston/Assigned To) -- - 65XFAIL update locally moved dir with incoming file move #4037(1.8.0/issues@subversion) 67XFAIL text mod to moved files #3144(1.8-consider/issues@subversion) #3630(unscheduled/issues@subversion) 68XFAIL text mod to
Re: RFC: Build system changes
On Thu, Dec 13, 2012 at 1:13 PM, Branko Čibej br...@wandisco.com wrote: The attached patch makes several changes to how we discover compilers and set flags on *nix: * Search for clang as well as the default gcc/cc, and prefer clang(++) over gcc/g++. * Set standards-compliance mode (C90/C++11) even without maintainer-mode. It seems a bit odd to allow use of C++11 features and yet still use C90 for the rest of the codebase. I realize the C++ code is largely limited to interfaces with lower-level libraries and bindings, but I would lean toward C++98, at least initially. (That is, unless you've got a compelling reason for rvalue references. :P ) -Hyrum
Re: RFC: Build system changes
On 14.12.2012 02:32, Hyrum K Wright wrote: On Thu, Dec 13, 2012 at 1:13 PM, Branko Čibej br...@wandisco.com wrote: The attached patch makes several changes to how we discover compilers and set flags on *nix: * Search for clang as well as the default gcc/cc, and prefer clang(++) over gcc/g++. * Set standards-compliance mode (C90/C++11) even without maintainer-mode. It seems a bit odd to allow use of C++11 features and yet still use C90 for the rest of the codebase. I realize the C++ code is largely limited to interfaces with lower-level libraries and bindings, but I would lean toward C++98, at least initially. (That is, unless you've got a compelling reason for rvalue references. :P ) The only reason for trying for C++11 is, as far as I'm concerned, getting std::shared_ptr memory. The C++ bindings I'm slowly wrapping my head around will need it, and I don't want to even consider using standard containers without it. The only alternative to C++11 is using Boost, and that's a last resort grabbing for straws, as far as I'm concerned. -- Brane P.S.: Nothing wrong with Boost as such, of course; but including boost/shared_ptr.hpp tends to pull in some 90% of Boost's headers, and I consider that overkill. -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: RFC: Build system changes
On Thu, Dec 13, 2012 at 10:21 PM, Branko Čibej br...@wandisco.com wrote: ... P.S.: Nothing wrong with Boost as such, of course; but including boost/shared_ptr.hpp tends to pull in some 90% of Boost's headers, and I consider that overkill. I'll go on record with Boost is the Automake of C++. Tons of useless crap that you don't actually need. I needed a couple boost bits for Apache Thrift, iirc, and to get them... ended up with something like 100k new files in /usr/local. Consider this my typical potty-mouth response. I'll skip the actuals, and move along in peace... -g
Re: RFC: Build system changes
On 14.12.2012 07:38, Miha Vitorovic wrote: On 14.12.2012 4:21, Branko Čibej wrote: The only reason for trying for C++11 is, as far as I'm concerned, getting std::shared_ptr memory. The C++ bindings I'm slowly wrapping my head around will need it, and I don't want to even consider using standard containers without it. The only alternative to C++11 is using Boost, and that's a last resort grabbing for straws, as far as I'm concerned. -- Brane P.S.: Nothing wrong with Boost as such, of course; but including boost/shared_ptr.hpp tends to pull in some 90% of Boost's headers, and I consider that overkill. If your only need is shared_ptr why not use std::tr1? A quick research shows that it's bundled with all compilers. Yes, I realised that and already changed the code that way. It's not exactly bundled with /all/ compilers, but that's a detail I wont' worry about right now. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
