Make ra_serf handle 408 Request Timeout response (was Re: Random serf checkout failures)
On Wed, Nov 7, 2012 at 10:28 PM, Lieven Govaerts l...@apache.org wrote: Hi, we seem to be raising and discussing a few different issues in this thread. I've tried to summarize current status with some added observations. I propose to start up separate mail threads when discussing one of these specific issues. [..] 5. In one of Philip error-reporting mails, there was mention of a 408 Request Time-out response. (http://svn.haxx.se/dev/archive-2012-11/0076.shtml). No idea if the server sends this response because one of the above issues, or if this has a different root caus. What I do know is that serf does not expect this response as it's not related to an outstanding request. In that case, serf will return and APR_GENERAL error. I've logged an issue in the serf project: https://code.google.com/p/serf/issues/detail?id=91 This needs to be fixed first, so that the 408 Request Timeout response is not considered an error, but is passed to svn like a normal response. In ra_serf/handle_response we can then decided what to do, like retrying the request once. [..] Lieven
RE: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: donderdag 8 november 2012 08:07 To: dev@subversion.apache.org Subject: Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py Branko Čibej wrote on Thu, Nov 08, 2012 at 06:13:22 +0100: On 08.11.2012 05:26, Daniel Shahaf wrote: Branko Čibej wrote on Thu, Nov 08, 2012 at 04:13:52 +0100: I believe that the correct approach would be to always treat a changed node kind (that's either the appearance/disappearance of the svn:symlink property, or a change of the initial keyword in the special-file contents) as if it were a replacement, for the purpose of conflict detection and resolution, even though the node didn't actually get replaced. Should we allow nodes to change their special-ness (namely: whether they have svn:special set, and if yes what's the initial keyword) without a replace? i.e., sure, current clients can do that --- svn ps svn:special yes COMMITTERS --- so we'll have to handle that in libsvn_wc. But maybe we shouldn't allow any more instances of that. Good point. It might be a good idea to simply forbid setting or deleting svn:special explicitly, and also refusing to commit the file if its contents were modified in a way that changes the special type. Effectively that means you could only create special files through indirect means, e.g., by svn adding a symlink. That wouldn't remove the work needed to fix the tree conflict bug, but it would make the svn:special semantics clearer. I personally don't think we have to worry about backward compatibility at that level; I'd rather treat the fact that you can directly manipulate svn:special as a bug. I would agree that being able to add/rm svn:special on a file node _that already exists in the repository_ is a bug. But being able to do that on a locally-added file is a feature --- it's what allows Windows users to create versioned symlinks: +1 on not allowing to change the symlinkness of existing files. And +1 on still allowing it on *new* files. In the update editor we could change the behavior of incoming symlink changes to be handled as a delete + add, introducing a tree conflict (and a local replacement of the incoming node to keep the original state) if there are local changes. I think I should be able to introduce this update editor behavior easily, but it is hard for me to test the on-disk symlink behavior. So I might break a few buildbot runs while working on this. Bert
RE: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: donderdag 8 november 2012 08:10 To: dev@subversion.apache.org Subject: Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py BTW, it would be nice if the recipe for creating versioned symlinks on Windows worked on Unixes too. For example, the 'svn add --with-revprop' command could replace 'foo' --- which would be a normal file at that point --- with an actual symlink. With 'revprop'? What? svn:special is not a revision property. Bert
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
Bert Huijben wrote on Thu, Nov 08, 2012 at 10:01:18 +0100:
-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: donderdag 8 november 2012 08:10
To: dev@subversion.apache.org
Subject: Re: svn commit: r1406870 - in /subversion/trunk/subversion:
libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c
tests/cmdline/special_tests.py
BTW, it would be nice if the recipe for creating versioned symlinks on
Windows worked on Unixes too. For example, the 'svn add --with-revprop'
command could replace 'foo' --- which would be a normal file at that
point --- with an actual symlink.
With 'revprop'?
What?
svn:special is not a revision property.
Doh. The point was to atomically ('svn add' and 'mark as
svn:special=symlink') --- obviously I got the --option name wrongly.
Bert
Re: svn commit: r1406967 - in /subversion/site/publish: docs/community-guide/repro-template.sh roadmap.html
danie...@apache.org wrote on Thu, Nov 08, 2012 at 09:03:48 -:
Author: danielsh
Date: Thu Nov 8 09:03:48 2012
New Revision: 1406967
URL: http://svn.apache.org/viewvc?rev=1406967view=rev
Log:
* roadmap.html: Typo fix
Modified:
subversion/site/publish/docs/community-guide/repro-template.sh
Committed by accident --- thanks, svn_opt_push_implicit_dot_target ---
but it's a reasonable change, so I left it in and edited the log message
accordingly.
subversion/site/publish/roadmap.html
Modified: subversion/site/publish/docs/community-guide/repro-template.sh
URL:
http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/repro-template.sh?rev=1406967r1=1406966r2=1406967view=diff
==
--- subversion/site/publish/docs/community-guide/repro-template.sh (original)
+++ subversion/site/publish/docs/community-guide/repro-template.sh Thu Nov 8
09:03:48 2012
@@ -22,6 +22,11 @@ if [ -z $SVN ]; then
SVNADMIN=`which svnadmin`
fi
+# Make sure we don't use $HOME/.subversion/.
+SVN=${SVN} --config-dir=./svn-repro-config-dir
+SVNADMIN=${SVNADMIN} --config-dir=./svn-repro-config-dir
+SVNSERVE=${SVNSERVE} --config-dir=./svn-repro-config-dir
+
# Use English output.
LC_ALL=C; export LC_ALL
Modified: subversion/site/publish/roadmap.html
URL:
http://svn.apache.org/viewvc/subversion/site/publish/roadmap.html?rev=1406967r1=1406966r2=1406967view=diff
==
--- subversion/site/publish/roadmap.html (original)
+++ subversion/site/publish/roadmap.html Thu Nov 8 09:03:48 2012
@@ -380,7 +380,7 @@ numbering, compatibility, and deprecatio
tr class=task-level-1 not-started
td class=task-nameReview private APIs/td
td class=task-statusNot Started/td
-tdReview private APIs (including APIs used by
ttsubversion/svn*//tt,
+tdReview private APIs (including APIs used by
ttsubversion/svn*//tt),
and determine which of them should be promoted to public./td
/tr
tr class=task-level-1 not-started
Re: [PATCH] Implement '--include-externals' option to 'svn list'
On Wednesday 07 November 2012 08:19 PM, Stefan Sperling wrote: On Wed, Nov 07, 2012 at 07:54:33PM +0530, vijay wrote: Thanks stefan for your detailed review. I will keep in mind all your review comments. I will correct my mistakes in future patches. Attached the updated patch and log message. This patch looks fine to me overall. I have one more additional suggestion though. Your patch uses boolean parameters to notify start end end of an external item listing. This forces function implementors to reason about all of these possibilities: What do I do if...: 1) notify_external_start == TRUE notify_external_end == TRUE 2) notify_external_start == TRUE notify_external_start == FALSE 3) notify_external_end == FALSE notify_external_end == TRUE 4) notify_external_end == FALSE notify_external_end == FALSE All this combined with the possible values for external_parent_url and external_target gives quite a few possibilities for implementors to reason about. I wonder if this interface can be simplified somehow, maybe by getting rid of these two boolean parameters. Instead, we could tell implementors that if external_parent_url and external_target are defined, the item being listed is part of the external described by external_parent_url and external_target. Else, the item is not part of any external. It would then be the implementor's responsibility to, for instance, properly open and close XML tags. To help with this, we can tell the implementor that we'll never mix items which are part of separate externals, and will always finish listing an external before listing the next one. I think your code already guarantees this anyway, so we can just make this guarantee explicit in the docstring of the svn_client_list_func2_t interface. Then we could make the callback implementation track state to detect by itself whether or not it is entering or leaving an external. The callback could keep track of the last seen external_parent_url and external_target pair, and open and close XML tags if they change. For an example of this approach, see the code in subversion/svn/notify.c which uses an 'in_external' boolean parameter in the notify_baton for a similar purpose. Does this suggestion make sense? Yes, stefan. It makes sense. Initially, I was struggling hard to implement this option without the two boolean parameters, notify_external_start and notify_external_end. I couldn't find any other way to do it. So I added the two parameters reluctantly. Now, I have an interesting suggestion. Let me dig through svn/notify.c and come up with an implementation. Thanks Regards, Vijayaguru
AW: Random serf checkout failures
Hi, Lieven, Von: lieven.govae...@gmail.com [] 5. In one of Philip error-reporting mails, there was mention of a 408 Request Time-out response. (http://svn.haxx.se/dev/archive-2012-11/0076.shtml). No idea if the server sends this response because one of the above issues, or if this has a different root caus. What I do know is that serf does not expect this response as it's not related to an outstanding request. In that case, serf will return and APR_GENERAL error. I think 3+4+5 are relatively easy to solve, but probably difficult to reproduce to validate the implemented solutions. 1a and 2 require more analysis, I'll try to focus on these two. I think 5 might be testable with a special version of mod_dontdothat which injects that error code, maybe conditionally or randomly. Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com CODESYS internet forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: [PATCH] enabling ruby in the subversion build
Michael Chletsos mpchl...@gmail.com writes: OK - this should fix your issues, tested on ruby1.9.3 and ruby1.8.7 - passed for me, let me know what you get. That works for me. It needs a log message before it can be committed. If you want to write it look at some old log messages and http://subversion.apache.org/docs/community-guide/conventions.html#log-messages for guidance. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
Bert Huijben b...@qqmail.nl writes: +1 on not allowing to change the symlinkness of existing files. And +1 on still allowing it on *new* files. In the update editor we could change the behavior of incoming symlink changes to be handled as a delete + add, introducing a tree conflict (and a local replacement of the incoming node to keep the original state) if there are local changes. To my surprise we have a related problem with file-directory changes: $ rm wc/file $ mkdir wc/file $ svn st wc ~ wc/file $ svn up wc# attempts to modify text of wc/file Uwc/file ../src/subversion/svn/update-cmd.c:168: (apr_err=21) ../src/subversion/libsvn_client/update.c:639: (apr_err=21) ../src/subversion/libsvn_client/update.c:579: (apr_err=21) ../src/subversion/libsvn_client/update.c:440: (apr_err=21) ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=21) ../src/subversion/libsvn_repos/reporter.c:1541: (apr_err=21) ../src/subversion/libsvn_repos/reporter.c:1456: (apr_err=21) ../src/subversion/libsvn_wc/update_editor.c:2748: (apr_err=21) ../src/subversion/libsvn_wc/workqueue.c:1491: (apr_err=21) ../src/subversion/libsvn_wc/workqueue.c:1409: (apr_err=21) ../src/subversion/libsvn_wc/workqueue.c:628: (apr_err=21) ../src/subversion/libsvn_subr/io.c:3559: (apr_err=21) svn: E21: Can't move '/home/pm/sw/subversion/obj/wc/.svn/tmp/svn-KLx0k0' to '/home/pm/sw/subversion/obj/wc/file': Is a directory I thought we addressed things like this in 1.7 but I see we didn't finish it. The obstruction prevents us updating the working file but it is entirely possible for the base tree to be updated. We probably don't need either a tree- or text- conflict here. If we simpy skip updating the file the obstruction will continue to be marked ~ in status. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: [PATCH] Implement '--include-externals' option to 'svn list'
On Wednesday 07 November 2012 08:57 PM, Stefan Fuhrmann wrote: On Wed, Nov 7, 2012 at 3:02 PM, vijay vi...@collab.net mailto:vi...@collab.net wrote: On Tuesday 06 November 2012 08:09 PM, Stefan Fuhrmann wrote: On Mon, Nov 5, 2012 at 5:24 PM, vijay vi...@collab.net mailto:vi...@collab.net mailto:vi...@collab.net mailto:vi...@collab.net wrote: Hi, This patch implements '--include-externals' option to 'svn list' [Issue #4225] [1]. All tests pass with 'make check' 'make davautocheck'. Attached the patch and log message. Please review this patch and share your thoughts. Thanks in advance for your time. Thanks Regards, Vijayaguru [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4225 http://subversion.tigris.org/__issues/show_bug.cgi?id=4225 http://subversion.tigris.org/__issues/show_bug.cgi?id=4225 http://subversion.tigris.org/issues/show_bug.cgi?id=4225 Hi Vijay, Not sure whether these points have already been discussed in previous threads, but the following two points caught my attention: +typedef svn_error_t *(*svn_client_list_func2_t)( + void *baton, + const char *path, + const svn_dirent_t *dirent, + const svn_lock_t *lock, + const char *abs_path, o.k. + svn_boolean_t notify_external_start, + svn_boolean_t notify_external_end, + const char *external_parent_url, + const char *external_target, Maybe, this should be modeled to create a more seamless appearance. Only keep the external_parent_url member. If it is NULL, this entry has not been pulled in here by some external. Otherwise it contains the parent URL as defined by your patch. I don't see the see the need to expose more information. Why would you need to group externals? The external_target member should be given implicitly by path / dirent. Am I missing something here? The external_target member will not be given by path / dirent. We will get it by parsing the externals description. Suppose that path1 in repo1 has svn:externals set to path2 in repo2. When we list path1 with externals included, 1. First, list path1. 2. Then, process all the externals defined under path1. Parse through the individual external description and populate external_target. For example, external description under path1: external_desc = exdir http://url-of-path2-in-repo2 external_target = exdir external_parent_url = http://url-of-path1-in-repo1 url of external = http://url-of-path2-in-repo2 3. List the entries by reaching 'url of external'. OK, I now see what you are trying to do here - I had read to much into the code. However, in this form, the added functionality is of limited use, IMHO. I understand that what you list is basically which paths you would get for a svn co $url. While this is fine, I see two issues with it: * trees don't get overlayed. Example: $svn ls $URL -R sub1 sub1/fileA sub1/fileB sub2 $svn propget svn:externals $URL http://somewhere/ sub1/subsub $svn ls $URL -R --include-externals sub1 sub1/fileA sub1/fileB sub2 sub1/subsub [external]. Desired output sub1 sub1/fileA sub1/fileB sub1/subsub [external @$URL]. sub2 I was referring externals related code base in checkout/update and export while implementing this option. From subversion/libsvn_client/update.c snip /* We handle externals after the update is complete, so that handling external items (and any errors therefrom) doesn't delay the primary operation. */ /snip So I preferred the same for 'list' also. But there is a difference in externals processing between the commands checkout/update and list. The former processes the externals by default. The latter processes externals only if we specifically ask it. What should we do here? * result of ls on a sub-folder results in less output $svn ls $URL/sub1 -R --include-externals fileA fileB Desired output: fileA fileB subsub [external @$URL]. Bert raised the same question and C-Mike answered here [1]. The current implementation uses svn_ra_get_dir() to fetch all properties and filters svn:externals under current list target. I don't know how to extend it for externals defined higher up in the tree. Thanks Regards, Vijayaguru [1] http://svn.haxx.se/dev/archive-2012-10/0353.shtml So, it is hard to build e.g. explorer-like GUIs based on this information. The GUI would still need to collect, remember and splice the externals manually. That would render your extension almost useless. -- Stefan^2.
ra_serf: truncated responses by low Timeout are not handled graceful (was Re: Random serf checkout failures)
Philip, On Tue, Nov 6, 2012 at 11:20 PM, Philip Martin philip.mar...@wandisco.com wrote: Lieven Govaerts l...@mobsol.be writes: Philip or Ben, can you test that with this patch svn will always stop with a communication error? Using serf 1.1.x patched and Subversion 1406366 I get this new error: Awc/1.3.0-rc1/subversion/libsvn_subr/config.c ../src/subversion/svn/checkout-cmd.c:168: (apr_err=120105) ../src/subversion/libsvn_client/checkout.c:179: (apr_err=120105) ../src/subversion/libsvn_client/update.c:579: (apr_err=120105) ../src/subversion/libsvn_client/update.c:440: (apr_err=120105) ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=120105) ../src/subversion/libsvn_ra_serf/update.c:2564: (apr_err=120105) ../src/subversion/libsvn_ra_serf/util.c:2028: (apr_err=120105) ../src/subversion/libsvn_ra_serf/util.c:2009: (apr_err=120105) ../src/subversion/libsvn_ra_serf/update.c:989: (apr_err=120105) svn: E120105: ra_serf: The server sent an improper HTTP response but I still see this as well: A wc/1.3.0-rc1/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/SVNAdmin.java ../src/subversion/libsvn_ra_serf/update.c:680: (apr_err=235000) svn: E235000: In file '../src/subversion/libsvn_ra_serf/update.c' line 680: assertion failed (! dir-ref_count) Program received signal SIGABRT, Aborted. 0x765ea475 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) p dir-ref_count $1 = 1 (gdb) bt #0 0x765ea475 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x765ed6f0 in *__GI_abort () at abort.c:92 #2 0x76feb5fd in svn_error_abort_on_malfunction (can_return=1, file=0x75b2ff78 ../src/subversion/libsvn_ra_serf/update.c, line=680, expr=0x75b3001e ! dir-ref_count) at ../src/subversion/libsvn_subr/error.c:678 #3 0x76feb64e in svn_error__malfunction (can_return=1, file=0x75b2ff78 ../src/subversion/libsvn_ra_serf/update.c, line=680, expr=0x75b3001e ! dir-ref_count) at ../src/subversion/libsvn_subr/error.c:703 #4 0x75b1edc0 in close_all_dirs (dir=0x71e810c8) at ../src/subversion/libsvn_ra_serf/update.c:680 #5 0x75b1ed4a in close_all_dirs (dir=0x71e830c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #6 0x75b1ed4a in close_all_dirs (dir=0x71e850c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #7 0x75b1ed4a in close_all_dirs (dir=0x71e870c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #8 0x75b1ed4a in close_all_dirs (dir=0x71e8d0c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #9 0x75b1ed4a in close_all_dirs (dir=0x720090c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #10 0x75b1ed4a in close_all_dirs (dir=0x7200b0c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #11 0x75b1ed4a in close_all_dirs (dir=0x720130c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #12 0x75b1ed4a in close_all_dirs (dir=0x724b90c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #13 0x75b1ed4a in close_all_dirs (dir=0x728f60c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #14 0x75b1ed4a in close_all_dirs (dir=0x732a10c8) at ../src/subversion/libsvn_ra_serf/update.c:676 #15 0x75b2420f in finish_report (report_baton=0x77e45090, pool=0x77e42028) at ../src/subversion/libsvn_ra_serf/update.c:2746 #16 0x7789bc6d in svn_wc_crawl_revisions5 (wc_ctx=0x732fd6b0, local_abspath=0x77e42168 /home/pm/sw/subversion/obj/wc, reporter=0x75d394e0, report_baton=0x77e45090, restore_files=1, depth=svn_depth_unknown, honor_depth_exclude=1, depth_compatibility_trick=0, use_commit_times=0, cancel_func=0x416b43 svn_cl__check_cancel, cancel_baton=0x0, notify_func=0x41c467 notify, notify_baton=0x732fd9a0, scratch_pool=0x77e42028) at ../src/subversion/libsvn_wc/adm_crawler.c:858 #17 0x77bc7f6d in update_internal (result_rev=0x0, local_abspath=0x77e42168 /home/pm/sw/subversion/obj/wc, anchor_abspath=0x77e438a0 /home/pm/sw/subversion/obj/wc, revision=0x7fffe050, depth=svn_depth_unknown, depth_is_sticky=0, ignore_externals=0, allow_unver_obstructions=0, adds_as_modification=1, timestamp_sleep=0x7fffe15c, notify_summary=1, ctx=0x732fd5f8, pool=0x77e42028) at ../src/subversion/libsvn_client/update.c:427 I can't reproduce this myself. Since this happens in the middle of the checkout (not explicitly mentioned in your mail but Ben showed me), and the close_all_dirs function is only called at the very end, when the full report has been parsed, this can be explained by a truncated REPORT response. Any
Re: Random serf checkout failures
Hi Markus, On Thu, Nov 8, 2012 at 12:02 PM, Markus Schaber m.scha...@codesys.com wrote: Hi, Lieven, Von: lieven.govae...@gmail.com [] 5. In one of Philip error-reporting mails, there was mention of a 408 Request Time-out response. (http://svn.haxx.se/dev/archive-2012-11/0076.shtml). No idea if the server sends this response because one of the above issues, or if this has a different root caus. What I do know is that serf does not expect this response as it's not related to an outstanding request. In that case, serf will return and APR_GENERAL error. I think 3+4+5 are relatively easy to solve, but probably difficult to reproduce to validate the implemented solutions. 1a and 2 require more analysis, I'll try to focus on these two. I think 5 might be testable with a special version of mod_dontdothat which injects that error code, maybe conditionally or randomly. I've found a way to trigger the issue with some modifications to serf, see the new email thread: http://svn.haxx.se/dev/archive-2012-11/0238.shtml Best regards Markus Schaber Lieven
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
Bert Huijben b...@qqmail.nl writes: In the update editor we could change the behavior of incoming symlink changes to be handled as a delete + add, introducing a tree conflict (and a local replacement of the incoming node to keep the original state) if there are local changes. I think I should be able to introduce this update editor behavior easily, but it is hard for me to test the on-disk symlink behavior. So I might break a few buildbot runs while working on this. We are currently adding a tree conflcit but we are not doing a good job: $ svn up wc --accept postpone Updating 'wc': C wc/f At revision 2. Summary of conflicts: Tree conflicts: 1 $ svn st wc D C wc/f local add, incoming add upon update Summary of conflicts: Tree conflicts: 1 We have flagged an add-add conflict but it's more of an update-update conflict. Also the working state is 'D' and that is probably never what the user wants. To get to state 'R' the user must resolve the tree conflict before doing the extra add. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: ra_serf: truncated responses by low Timeout are not handled graceful
Lieven Govaerts l...@apache.org writes: Any truncated response should now result in an error from serf (since serf trunk r1678). It's not clear to me if this error SERF_ERROR_TRUNCATED_HTTP_RESPONSE was returned from serf but then ignored in svn, or not returned at all. I was using 1.1.x with the patches you and Ivan posted so it would not have been returning that error. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
AW: Random serf checkout failures
Hi, Lieven, Von: lieven.govae...@gmail.com [mailto:lieven.govae...@gmail.com] Im On Thu, Nov 8, 2012 at 12:02 PM, Markus Schaber m.scha...@codesys.com wrote: Von: lieven.govae...@gmail.com [] 5. In one of Philip error-reporting mails, there was mention of a 408 Request Time-out response. (http://svn.haxx.se/dev/archive-2012-11/0076.shtml). No idea if the server sends this response because one of the above issues, or if this has a different root caus. What I do know is that serf does not expect this response as it's not related to an outstanding request. In that case, serf will return and APR_GENERAL error. I think 3+4+5 are relatively easy to solve, but probably difficult to reproduce to validate the implemented solutions. 1a and 2 require more analysis, I'll try to focus on these two. I think 5 might be testable with a special version of mod_dontdothat which injects that error code, maybe conditionally or randomly. I've found a way to trigger the issue with some modifications to serf, see the new email thread: http://svn.haxx.se/dev/archive-2012-11/0238.shtml I'm happy to hear that. Another possibility we could keep in mind for future incidents might be a special http proxy for fault injection. http://spareclockcycles.org/2010/06/10/sergio-proxy-released/ http://extradata.com/products/FaultFactory/ https://www.owasp.org/index.php/Category%3aOWASP_WebScarab_Project Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com CODESYS internet forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Authz on Collection of Repositories
On 5 nov 2012, at 09:11, Branko Čibej wrote: On 05.11.2012 00:21, Thomas Åkesson wrote: I did some tests with curl --head just as a sanity check. It seems to be a good choice for access control. I primarily wanted to see that HEAD requests were not allowed in situations where GET is not (e.g. when user has access in directories below). The HEAD requests I performed (minimal curl command) did not cause the server to provide Content-Length when returning 200 OK. Which is precisely what I was talking about in my other post. Such HEAD responses are invalid. If we implement HEAD, we have to do it correctly. Right, I was just confirming that. I think this is approaching off-topic for this thread. The server (mod_dav_svn) currently does respond to HEAD requests without Content-Length, which appears to be invalid. Perhaps a separate issue/thread should discuss whether the HEAD response should be changed to conform with the specification. On-topic, looking at the HTTP RFC, the HEAD request makes a lot of sense for access control purposes and that gives the server a chance to optimize the response even if, worst case, only the response bandwidth would be gained. /Thomas Å.
Re: [PATCH] Implement '--include-externals' option to 'svn list'
On Thu, Nov 08, 2012 at 05:04:35PM +0530, vijay wrote: On Wednesday 07 November 2012 08:57 PM, Stefan Fuhrmann wrote: * result of ls on a sub-folder results in less output $svn ls $URL/sub1 -R --include-externals fileA fileB Desired output: fileA fileB subsub [external @$URL]. Bert raised the same question and C-Mike answered here [1]. I think we should get something based on your current patch committed. It is already much better than not listing externals at all. Unless others have strong objections, of course. In that case you'll need to rework your current patch before it can be committed. With the benefit of hindsight, it seems allowing externals to be configured on any ancestor directory was a big mistake in the design that complicates things for no good reason. But that's neither your nor my fault :) The current implementation uses svn_ra_get_dir() to fetch all properties and filters svn:externals under current list target. I don't know how to extend it for externals defined higher up in the tree. Before listing, you could walk the repository tree from the target upwards to the repository root, and then while listing also process any externals definitions found on ancestors if they affect the list target. You'll need to deal with problems like authz restrictions while traversing upwards. So I'd suggest working on this problem in a follow-up patch, which should also include a new test case of course. Your current patch is already complex enough for me to review so I wouldn't want it to grow much larger before it can be committed.
Re: Please review Symmetric Merge
Paul Burba wrote: On Fri, Nov 2, 2012 at 5:29 PM, Paul Burba wrote: What about all these two XFailing tests? merge_automatic_tests.py 16 'cherry2_fwd' merge_automatic_tests.py 17 'cherry3_fwd Are you working on those? Are they blockers for 1.8? Any existing issue they can be associated with? Julian - just pinging you about this. These two tests are among a handful left that are set to XFail but which aren't associated with any known issue. Having an associated issue allows us to see at a glance what XFailing tests are 1.8 blockers as we plod on towards a release. OK, I've associated them with new issue #4255, Automatic merge ignores some cherry-picks, causing conflicts, and left them as XFail. (And I'm not working on fixing them, since it's a long-standing deficiency, not a regression.) - Julian
Re: Authz on Collection of Repositories
On 5 nov 2012, at 00:21, Thomas Åkesson wrote: I have meant to set up a test server with our reference configuration to validate the patch under realistic circumstances. Unfortunately, the SLES activation servers have been down for several hours (we don't have dev tools on our VM Appliance by default). I will do some tests with parentpath under /svn/ and both variations of Satisfy as soon as possible. Right, it took a while to get that test server up and running with the dev setup. I had to refresh some knowledge. I have performed the following tests with patch 2012-11-02. All tests with access file configured and Require valid-user. Parentpath on /svn/ and Satisfy Any: - Access without auth displays repositories with anonymous access, auth is not requested. - Access with auth displays filtered list. Works well when browser has previously been on an authenticated path. This is the situation when Satisfy Any and filtered Collection of Repositories does not work well. - Did a test with AuthzSVNAnonymous Off, which gave the quite surprising result that all content was listed both on Collection of Repositories and within the repositories. I doubt this is the intended behaviour?!? Parentpath on /svn/ and Satisfy All: - Authentication is required everywhere and the Collection of Repositories is beautifully filtered. Works very well with improved user experience on many installations. AuthzSVNAnonymous seems to have no effect in this case, which is expected. Parentpath on /: Tested both Satisfy Any/All with same results as on /svn/. Good, I had some concerns since there have historically been issues. The remaining concerns I have: - The combination of this patch with Satisfy Any. I am a bit more concerned than I was initially. - What is going on with AuthzSVNAnonymous Off? I will do more analysis of the code (focusing on access_checker in mod_authz_svn.c) but it would be great if someone could elaborate a bit on the intent. Thanks, Thomas Å.
Re: Please review Symmetric Merge
On Thu, Nov 8, 2012 at 9:49 AM, Julian Foad julianf...@btopenworld.com wrote: Paul Burba wrote: On Fri, Nov 2, 2012 at 5:29 PM, Paul Burba wrote: What about all these two XFailing tests? merge_automatic_tests.py 16 'cherry2_fwd' merge_automatic_tests.py 17 'cherry3_fwd Are you working on those? Are they blockers for 1.8? Any existing issue they can be associated with? Julian - just pinging you about this. These two tests are among a handful left that are set to XFail but which aren't associated with any known issue. Having an associated issue allows us to see at a glance what XFailing tests are 1.8 blockers as we plod on towards a release. OK, I've associated them with new issue #4255, Automatic merge ignores some cherry-picks, causing conflicts, and left them as XFail. (And I'm not working on fixing them, since it's a long-standing deficiency, not a regression.) Great, thanks Julian. I set the target milestone on the issue to unscheduled, since this isn't a 1.8 blocker (all those issues in the tracker with no target milestones give me a rash since it makes it hard to determine what needs to be fixed before 1.8 :-) -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
RE: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS
-Original Message- From: phi...@apache.org [mailto:phi...@apache.org] Sent: donderdag 8 november 2012 16:27 To: comm...@subversion.apache.org Subject: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS Author: philip Date: Thu Nov 8 15:26:37 2012 New Revision: 1407127 Approved changes: = + + * r1401915 + Ignore file externals with mergeinfo when merging. + Justification: + Prevents a segfault, + see http://svn.haxx.se/dev/archive-2012-10/0364.shtml + Branch: + ^/subversion/branches/1.7.x-r1401915 + Votes: + +1: pburba, steveking, philip In my original review of this patch I asked if this issue was more generic than just file externals? What happens with switched files? (Did I miss an earlier answer?) My guess would be that it is the being switched that defines the behavior here, not being external. And in that case a follow up patch would be necessary to handle the real problem. Bert
RE: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
-Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: donderdag 8 november 2012 13:31 To: Bert Huijben Cc: 'Daniel Shahaf'; dev@subversion.apache.org Subject: Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py Bert Huijben b...@qqmail.nl writes: In the update editor we could change the behavior of incoming symlink changes to be handled as a delete + add, introducing a tree conflict (and a local replacement of the incoming node to keep the original state) if there are local changes. I think I should be able to introduce this update editor behavior easily, but it is hard for me to test the on-disk symlink behavior. So I might break a few buildbot runs while working on this. We are currently adding a tree conflcit but we are not doing a good job: $ svn up wc --accept postpone Updating 'wc': C wc/f At revision 2. Summary of conflicts: Tree conflicts: 1 $ svn st wc D C wc/f local add, incoming add upon update Summary of conflicts: Tree conflicts: 1 We have flagged an add-add conflict but it's more of an update-update conflict. Also the working state is 'D' and that is probably never what the user wants. To get to state 'R' the user must resolve the tree conflict before doing the extra add. After r1407131 you would get something like: s-reverse and s-type are the changes from file into symlink and the other way $ svn up svn-test-work\working_copies\special_tests-25 Updating 'svn-test-work\working_copies\special_tests-25': Usvn-test-work\working_copies\special_tests-25\s-in-place C svn-test-work\working_copies\special_tests-25\s-replace A svn-test-work\working_copies\special_tests-25\s-replace C svn-test-work\working_copies\special_tests-25\s-reverse C svn-test-work\working_copies\special_tests-25\s-type Updated to revision 5. Summary of conflicts: Tree conflicts: 3 $ svn status -u svn-test-work\working_copies\special_tests-25 RM + C -2 jrandom svn-test-work\working_copies\special_tests-25\s-replace local edit, incoming replace upon update RM + C -2 jrandom svn-test-work\working_copies\special_tests-25\s-reverse local edit, incoming replace upon update RM + C -2 jrandom svn-test-work\working_copies\special_tests-25\s-type local edit, incoming replace upon update M 53 jrandom svn-test-work\working_copies\special_tests-25\s-in-place When the files/symlinks were locally modified before the update. (If the files weren't modified the update just handles the update, as with a normal replacement) As part of this work I enabled quite a few special tests on Windows, to at least get into these code paths from the test suite. Bert -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS
On Thu, Nov 8, 2012 at 10:32 AM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: phi...@apache.org [mailto:phi...@apache.org] Sent: donderdag 8 november 2012 16:27 To: comm...@subversion.apache.org Subject: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS Author: philip Date: Thu Nov 8 15:26:37 2012 New Revision: 1407127 Approved changes: = + + * r1401915 + Ignore file externals with mergeinfo when merging. + Justification: + Prevents a segfault, + see http://svn.haxx.se/dev/archive-2012-10/0364.shtml + Branch: + ^/subversion/branches/1.7.x-r1401915 + Votes: + +1: pburba, steveking, philip In my original review of this patch I asked if this issue was more generic than just file externals? What happens with switched files? (Did I miss an earlier answer?) Sorry Bert, I missed your reply to r1401915. Reintegrate merges and automatic merges which follow the same code path, don't allow the merge to proceed if there are switched subtrees present. You can use --ignore-ancestry to force the latter to run, but then mergetracking isn't active so the segfault is not an issue since it occurs find_unmerged_mergeinfo, which is only run in mergetracking aware reintegrate type merges. Alternatively you can use a 2-URL merge, but that doesn't hit the reintegrate merge code path either. So as of right now I don't see any further problems. -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba My guess would be that it is the being switched that defines the behavior here, not being external. And in that case a follow up patch would be necessary to handle the real problem. Bert -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
RE: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS
-Original Message- From: Paul Burba [mailto:ptbu...@gmail.com] Sent: donderdag 8 november 2012 17:13 To: Bert Huijben Cc: dev@subversion.apache.org Subject: Re: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS On Thu, Nov 8, 2012 at 10:32 AM, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: phi...@apache.org [mailto:phi...@apache.org] Sent: donderdag 8 november 2012 16:27 To: comm...@subversion.apache.org Subject: svn commit: r1407127 - /subversion/branches/1.7.x/STATUS Author: philip Date: Thu Nov 8 15:26:37 2012 New Revision: 1407127 Approved changes: = + + * r1401915 + Ignore file externals with mergeinfo when merging. + Justification: + Prevents a segfault, + see http://svn.haxx.se/dev/archive-2012-10/0364.shtml + Branch: + ^/subversion/branches/1.7.x-r1401915 + Votes: + +1: pburba, steveking, philip In my original review of this patch I asked if this issue was more generic than just file externals? What happens with switched files? (Did I miss an earlier answer?) Sorry Bert, I missed your reply to r1401915. Reintegrate merges and automatic merges which follow the same code path, don't allow the merge to proceed if there are switched subtrees present. You can use --ignore-ancestry to force the latter to run, but then mergetracking isn't active so the segfault is not an issue since it occurs find_unmerged_mergeinfo, which is only run in mergetracking aware reintegrate type merges. Alternatively you can use a 2-URL merge, but that doesn't hit the reintegrate merge code path either. So as of right now I don't see any further problems. Thanks for the explanation, In that case +1 on backporting :) Bert
Content-Length in HEAD responses (was: Re: Authz on Collection of Repositories)
Thomas Åkesson wrote on Thu, Nov 08, 2012 at 15:15:03 +0100: On 5 nov 2012, at 09:11, Branko Čibej wrote: On 05.11.2012 00:21, Thomas Åkesson wrote: I did some tests with curl --head just as a sanity check. It seems to be a good choice for access control. I primarily wanted to see that HEAD requests were not allowed in situations where GET is not (e.g. when user has access in directories below). The HEAD requests I performed (minimal curl command) did not cause the server to provide Content-Length when returning 200 OK. Which is precisely what I was talking about in my other post. Such HEAD responses are invalid. If we implement HEAD, we have to do it correctly. Right, I was just confirming that. I think this is approaching off-topic for this thread. The server (mod_dav_svn) currently does respond to HEAD requests without Content-Length, which appears to be invalid. Perhaps a separate issue/thread should discuss whether the HEAD response should be changed to conform with the specification. We could also add Content-Length if it's not required but cheap to compute. (svn_fs_file_length()) On-topic, looking at the HTTP RFC, the HEAD request makes a lot of sense for access control purposes and that gives the server a chance to optimize the response even if, worst case, only the response bandwidth would be gained. /Thomas Å.
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
[Daniel Shahaf] it's what allows Windows users to create versioned symlinks: printf link bar foo svn add foo svn ps svn:special yes foo svn ci If we don't like changing the specialness of a local addition, we could deprecate (or break) that behaviour and have people run 'svn add --with-revprop svn:special=yes foo' instead. (Where we understand you didn't actually mean 'revprop'.) We have that option already ... unfortunately it doesn't actually work: $ echo bar foo $ svn add --config-option config:miscellany:enable-auto-props=yes \ --config-option config:auto-props:foo=svn:special=1 foo A foo $ ls -l foo -rw-r--r-- 1 peters peters 4 Nov 8 10:57 foo $ svn ci -mm svn: E145001: Commit failed (details follow): svn: E145001: Entry '/tmp/foowc/foo' has unexpectedly changed special status Peter
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
Peter Samuelson wrote on Thu, Nov 08, 2012 at 11:01:37 -0600: [Daniel Shahaf] it's what allows Windows users to create versioned symlinks: printf link bar foo svn add foo svn ps svn:special yes foo svn ci If we don't like changing the specialness of a local addition, we could deprecate (or break) that behaviour and have people run 'svn add --with-revprop svn:special=yes foo' instead. (Where we understand you didn't actually mean 'revprop'.) We have that option already ... unfortunately it doesn't actually work: Time to file a bug report, then! (Good catch) $ echo bar foo $ svn add --config-option config:miscellany:enable-auto-props=yes \ --config-option config:auto-props:foo=svn:special=1 foo A foo $ ls -l foo -rw-r--r-- 1 peters peters 4 Nov 8 10:57 foo $ svn ci -mm svn: E145001: Commit failed (details follow): svn: E145001: Entry '/tmp/foowc/foo' has unexpectedly changed special status Peter
Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125 [was: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build]
Stefan Fuhrmann wrote: But I did run across an assertion in mergeinfo.c, :line 1174 during merge_tests.py 125: SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first)); The weird thing about the assertion is, that the tests will continue just fine afterwards and no error was reported. I suspect some compiler optimization issue or some missing initialization. I see this too. The test is marked XFAIL. - Julian
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
Peter Samuelson wrote on Thu, Nov 08, 2012 at 11:01:37 -0600: [Daniel Shahaf] it's what allows Windows users to create versioned symlinks: printf link bar foo svn add foo svn ps svn:special yes foo svn ci If we don't like changing the specialness of a local addition, we could deprecate (or break) that behaviour and have people run 'svn add --with-revprop svn:special=yes foo' instead. (Where we understand you didn't actually mean 'revprop'.) We have that option already ... unfortunately it doesn't actually work: $ echo bar foo Did you mean: $ printf 'link bar' foo $ svn add --config-option config:miscellany:enable-auto-props=yes \ --config-option config:auto-props:foo=svn:special=1 foo A foo $ ls -l foo -rw-r--r-- 1 peters peters 4 Nov 8 10:57 foo $ svn ci -mm svn: E145001: Commit failed (details follow): svn: E145001: Entry '/tmp/foowc/foo' has unexpectedly changed special status Given that bar\n does not start with link , I think this commit should have succeeded. (Just like the printf 'link bar' variant succeeds on windows) Peter
Re: [PATCH] enabling ruby in the subversion build
Initial support for ruby 1.9.3 when creating swig bindings for subversion. * Makefile.in: Ruby 1.8 uses --verbose, 1.9 does not for run-test.rb * subversion/bindings/swig/ruby/test/test_core.rb: Updated for ruby1.9 time, which uses nanoseconds * subversion/bindings/swig/ruby/test/test_repos.rb: ruby1.8 carries the assignment through block, ruby1.9 does not carry assignments, we need to explicitly do this. * subversion/bindings/swig/ruby/test/test-unit-ext/priority.rb: run priority tests only for ruby1.8 * subversion/bindings/swig/ruby/test/test_delta.rb: fix nil return in ruby1.9, ruby1.8 carries the assignment through block, ruby1.9 does not carry assignments, we need to explicitly do this fix StringIO encoding to be ASCII-8BIT, no longer assumed as in ruby1.8 * subversion/bindings/swig/ruby/test/test-unit-ext.rb: turn off some tests for ruby1.9, they should be fixed still * subversion/bindings/swig/ruby/test/test_fs.rb: update md5 to digest/md5 in require * subversion/bindings/swig/ruby/test/test_wc.rb, subversion/bindings/swig/ruby/test/test_client.rb: ruby1.8 carries the assignment through block, ruby1.9 does not carry assignments, we need to explicitly do this * subversion/bindings/swig/ruby/test/my-assertions.rb: create intermediary assertion block handler * subversion/bindings/swig/ruby/svn/util.rb: convert to string before splitting for ruby1.9 compat * subversion/bindings/swig/ruby/svn/info.rb: use each_line for ruby1.9 and each for ruby1.8 * configure.ac: detect ruby1.9.3 - added teeny version detection restrict build to 1.8.x and = 1.9.3 Patch by: Michael Chletsos mpchl...@gmail.com, Vincent Batts vba...@slackware.com On Thu, Nov 8, 2012 at 1:03 AM, Philip Martin philip.mar...@wandisco.com wrote: Michael Chletsos mpchl...@gmail.com writes: OK - this should fix your issues, tested on ruby1.9.3 and ruby1.8.7 - passed for me, let me know what you get. That works for me. It needs a log message before it can be committed. If you want to write it look at some old log messages and http://subversion.apache.org/docs/community-guide/conventions.html#log-messages for guidance. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1406870 - in /subversion/trunk/subversion: libsvn_wc/update_editor.c libsvn_wc/wc_db_wcroot.c tests/cmdline/special_tests.py
[Daniel Shahaf] Did you mean: $ printf 'link bar' foo Yes I did mean that - thanks. $ svn add --config-option config:miscellany:enable-auto-props=yes \ --config-option config:auto-props:foo=svn:special=1 foo A foo $ ls -l foo -rw-r--r-- 1 peters peters 4 Nov 8 10:57 foo $ svn ci -mm svn: E145001: Commit failed (details follow): svn: E145001: Entry '/tmp/foowc/foo' has unexpectedly changed special status Given that bar\n does not start with link , I think this commit should have succeeded. (Just like the printf 'link bar' variant succeeds on windows) Or, alternately, it should have failed because svn does not recognise the 'bar' special type. Anyway, we discussed this a bit on IRC and further discovered: - 'svn add' with auto-props fails on Unix but succeeds on Windows, presumably because the subsequent 'commit' does not expect to find a literal symlink on Windows. - 'svn propset svn:special' behaves the same: it does not convert a file into a symlink, therefore on Unix the subsequent commit fails. - For a different case, svn:executable, both 'svn add' with auto-props and 'svn propset' have the correct side effect of making the file executable. So to me it looks like 'svn add' with autoprops is a working subsitute for 'svn propset'. Apparently both methods can be used to create a symlink in Windows. Neither can be used to create a symlink in Unix. The bug in which setting the 'svn:special' property does not transform a file into the appropriate special type is a different issue, not specific to 'svn add' with auto-props. That bug should not prevent us from restricting 'propset' / 'propedit' / 'svn propdel' of svn:special, if we so desire. Final point: '--auto-props --config-option config:auto-props:*=a=b' is certainly a bit cumbersome - we may want a new convenience option 'svn add --with-prop a=b'. (Nothing to do with svn:special per se, this could be used for any file props, as a shortcut.) But for the present thread, creating a symlink on Windows is today is already not very intuitive for most users, I would guess. They probably already have to look up the 'propset' line in a tutorial or cookbook. Peter
Re: [PATCH] enabling ruby in the subversion build
Thank you! Ruby community will be excited, I will continue to improve the tests. On Thu, Nov 8, 2012 at 8:29 AM, Philip Martin philip.mar...@wandisco.com wrote: Michael Chletsos mpchl...@gmail.com writes: Initial support for ruby 1.9.3 when creating swig bindings for subversion. I tweaked the format a little and committed in r1407206. Thanks! -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: [PATCH] enabling ruby in the subversion build
Michael Chletsos mpchl...@gmail.com writes: Initial support for ruby 1.9.3 when creating swig bindings for subversion. I tweaked the format a little and committed in r1407206. Thanks! -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: ra_serf: truncated responses by low Timeout are not handled graceful
Hi, On Thu, Nov 8, 2012 at 1:34 PM, Philip Martin philip.mar...@wandisco.com wrote: Lieven Govaerts l...@apache.org writes: Any truncated response should now result in an error from serf (since serf trunk r1678). It's not clear to me if this error SERF_ERROR_TRUNCATED_HTTP_RESPONSE was returned from serf but then ignored in svn, or not returned at all. I was using 1.1.x with the patches you and Ivan posted so it would not have been returning that error. The patch I sent you earlier used another error code, but the result should be the same. You saw that in your logs as error The server sent an improper HTTP response. That patch only checked bodies for responses with Content-Length header. The REPORT response is chunked encoded, hence no error was reported by serf when the server aborted the REPORT response connection. I've added a similar check for chunked-encoded response bodies in serf r1685. My expectation is that with serf trunk up to date r1685 you'll now only see the error The server sent a truncated HTTP response body. instead of asserts, checksum or other svn errors. Lieven
Issue #4239 'svn mergeinfo' should show a user-friendly summary
C-Mike Pilato asks in http://subversion.tigris.org/issues/show_bug.cgi?id=4239, Julian, what is the exit criteria for this issue's completion? At what point do we call it finished -- or at least finished enough that future improvements can be tracked as unique issues? I guess there are two questions. 1. Do folks feel it's sufficiently operative to be released in its current state, if it should happen that we get around to releasing 1.8 before I do any more work on it, and if no-one else does any more work on it? 2. What exactly should issue #4239 be tracking -- a specific actionable item, or an open list of ideas for improvement (by reference to the wiki page)? Personally, I feel for question (1) yes, it's just about enough to be worth releasing, although of course I'd like more, and for (2) I'd be inclined to change the issue summary to enhancements to the mergeinfo summary, change the milestone to unscheduled, and the priority to a bit lower. If no-one has other ideas, I'll update the issue accordingly. - Julian
Re: Issue #4239 'svn mergeinfo' should show a user-friendly summary
On 11/08/2012 03:50 PM, Julian Foad wrote: C-Mike Pilato asks in http://subversion.tigris.org/issues/show_bug.cgi?id=4239, Julian, what is the exit criteria for this issue's completion? At what point do we call it finished -- or at least finished enough that future improvements can be tracked as unique issues? I guess there are two questions. 1. Do folks feel it's sufficiently operative to be released in its current state, if it should happen that we get around to releasing 1.8 before I do any more work on it, and if no-one else does any more work on it? 2. What exactly should issue #4239 be tracking -- a specific actionable item, or an open list of ideas for improvement (by reference to the wiki page)? Personally, I feel for question (1) yes, it's just about enough to be worth releasing, although of course I'd like more, and for (2) I'd be inclined to change the issue summary to enhancements to the mergeinfo summary, change the milestone to unscheduled, and the priority to a bit lower. If no-one has other ideas, I'll update the issue accordingly. I would agree with (1). Haven't used the feature extensively, but I did play with a handful of scenarios just to see what it did. I'm not a huge fan of open-ended issues such as you suggest for (2), because every time a commit is made toward that issue, the dev has to evaluate whether completion of the task has been achieved. Not sure which is the bigger evil, though: open-ended long-running issues, or the proliferation of tiny related task issues. Maybe something in-between? *shrug. No strong opinion here. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: ra_serf: truncated responses by low Timeout are not handled graceful
Lieven Govaerts l...@apache.org writes: My expectation is that with serf trunk up to date r1685 you'll now only see the error The server sent a truncated HTTP response body. instead of asserts, checksum or other svn errors. I do see that error: ../src/subversion/svn/checkout-cmd.c:168: (apr_err=120106) ../src/subversion/libsvn_client/checkout.c:179: (apr_err=120106) ../src/subversion/libsvn_client/update.c:579: (apr_err=120106) ../src/subversion/libsvn_client/update.c:440: (apr_err=120106) ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=120106) ../src/subversion/libsvn_ra_serf/update.c:2564: (apr_err=120106) ../src/subversion/libsvn_ra_serf/util.c:2028: (apr_err=120106) ../src/subversion/libsvn_ra_serf/util.c:2009: (apr_err=120106) ../src/subversion/libsvn_ra_serf/util.c:1574: (apr_err=120106) svn: E120106: ra_serf: The server sent a truncated HTTP response body. I also see: ../src/subversion/svn/checkout-cmd.c:168: (apr_err=175009) ../src/subversion/libsvn_client/checkout.c:179: (apr_err=175009) ../src/subversion/libsvn_client/update.c:579: (apr_err=175009) ../src/subversion/libsvn_client/update.c:440: (apr_err=175009) ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=175009) ../src/subversion/libsvn_ra_serf/update.c:2564: (apr_err=175009) ../src/subversion/libsvn_ra_serf/util.c:2028: (apr_err=175009) ../src/subversion/libsvn_ra_serf/util.c:1850: (apr_err=175009) svn: E175009: Premature EOF seen from server (http status=200) ../src/subversion/libsvn_ra_serf/util.c:1850: (apr_err=70014) svn: E070014: End of file found and with mod_deflate enabled I also see: ../src/subversion/svn/checkout-cmd.c:168: (apr_err=120104) ../src/subversion/libsvn_client/checkout.c:179: (apr_err=120104) ../src/subversion/libsvn_client/update.c:579: (apr_err=120104) ../src/subversion/libsvn_client/update.c:440: (apr_err=120104) ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=120104) ../src/subversion/libsvn_ra_serf/update.c:2564: (apr_err=120104) ../src/subversion/libsvn_ra_serf/util.c:2028: (apr_err=120104) ../src/subversion/libsvn_ra_serf/util.c:2009: (apr_err=120104) ../src/subversion/libsvn_ra_serf/update.c:989: (apr_err=120104) svn: E120104: ra_serf: An error occurred during decompression which is probably that same EOF error during inflation. Using serf trunk@1685, subversion trunk@1407208. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1407279 - in /subversion/trunk/subversion: svnadmin/main.c tests/cmdline/svntest/main.py
On Thu, Nov 08, 2012 at 09:42:34PM -, cmpil...@apache.org wrote: Author: cmpilato Date: Thu Nov 8 21:42:34 2012 New Revision: 1407279 URL: http://svn.apache.org/viewvc?rev=1407279view=rev Log: Rather than continue the trend of accumulating new --pre-X.Y-compatible options to 'svnadmin create', make use of the new version parsing and comparison private functions to add a single new option that should work henceforth. Nice!!! + /* In 1.8, we figured out that we didn't have to keep extending this + madness indefinitely. */ xactly! :)
Re: Issue #4239 'svn mergeinfo' should show a user-friendly summary
C. Michael Pilato wrote: On 11/08/2012 03:50 PM, Julian Foad wrote: C-Mike Pilato asks in http://subversion.tigris.org/issues/show_bug.cgi?id=4239, Julian, what is the exit criteria for this issue's completion? At what point do we call it finished -- or at least finished enough that future improvements can be tracked as unique issues? I guess there are two questions. 1. Do folks feel it's sufficiently operative to be released in its current state, if it should happen that we get around to releasing 1.8 before I do any more work on it, and if no-one else does any more work on it? 2. What exactly should issue #4239 be tracking -- a specific actionable item, or an open list of ideas for improvement (by reference to the wiki page)? Personally, I feel for question (1) yes, it's just about enough to be worth releasing, although of course I'd like more, and for (2) I'd be inclined to change the issue summary to enhancements to the mergeinfo summary, change the milestone to unscheduled, and the priority to a bit lower. If no-one has other ideas, I'll update the issue accordingly. I would agree with (1). Haven't used the feature extensively, but I did play with a handful of scenarios just to see what it did. I'm not a huge fan of open-ended issues such as you suggest for (2), because every time a commit is made toward that issue, the dev has to evaluate whether completion of the task has been achieved. Not sure which is the bigger evil, though: open-ended long-running issues, or the proliferation of tiny related task issues. Maybe something in-between? *shrug. No strong opinion here. Maybe now that we have the Wiki, it can start to take over the roles of wish-list, idea collecting and so on, that we have sometimes used the issue tracker for in the past. - Julian
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build
On Thu, Nov 8, 2012 at 7:30 AM, Stefan Fuhrmann stefan.fuhrm...@wandisco.com wrote: On Tue, Nov 6, 2012 at 10:29 PM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Nov 6, 2012 at 10:53 AM, Stefan Fuhrmann stefan.fuhrm...@wandisco.com wrote: On Mon, Nov 5, 2012 at 2:00 AM, Johan Corveleyn jcor...@gmail.com wrote: Before I look into this further, I'd like to know if anyone else has seen this or can reproduce this (or doesn't reproduce this with a similar environment) ... Tests 12 and 15 of mergeinfo-test.exe and test 4 of skel-test.exe hang on my machine (i.e. they don't do anything useful anymore, but do fully consume a cpu core until I kill them). This is with trunk@1405553. All other tests, except the above three, run successfully for me. I'm running Windows XP (32 bit). I only see this happening with a release build (shared; haven't tried with --disable-shared yet), when compiled with VS 2010. I do *not* see this (i.e. tests complete normally) with: - debug build made with VS 2010. - release or debug builds made with VSExpress 2008. Does anyone else have a release build on (any) Windows, made with VS 2010, and can run these tests? I'm using these dependencies: Httpd 2.2.22 Apr 1.4.5 Apr-Util 1.4.1 Apr-Iconv 1.2.1 OpenSSL 1.0.1c Serf 1.1.1 SQLite 3.7.14.1 ZLib 1.2.6 They don't hang for me but I'm using a slightly older SQLite version. However, there has been a similar issue under Linux when running the tests in parallel. Python 2.7.2(?) has a sync. issue. Maybe, try updating your python installation. Thanks a lot for taking a look, Stefan. I have tried again with SQLite 3.7.12, but the result is the same. You did use VC2010 for compilation, and tried with a release build, right? Yes, with SP1. Aha, I don't have SP1 installed apparently (I remember I had some problems with the installation of SP1, caused by general Windows installation problems). Now, I have pinpointed the exact revision where the problems start for me. It's r1338286, where Bert enabled whole program optimizations for release builds, in the vcnet_vcxproj.ezt file. Maybe I'm running into some compiler bug (that has since been fixed in SP1), related to whole program optimization. I'll try installing SP1 (but not right now, it's past 3 am now :-)) and see what happens. Thanks for your help, Stefan. -- Johan
