[PATCH] Make ra_serf be more aggressive about closing directories in update
One issue that I've come across in my recent analysis is that ra_serf
isn't always aggressive in closing directories when doing an update.
Specifically, when the directory propfind isn't received by the time
all of the files are processed, ra_serf won't look at the directory
handle again until everything is complete. (It only evaluates when
closing the files.) When doing a large checkout (like tags/), this
can be a bit problematic as we really need to be aggressive in
reclaiming all of the pools to keep our memory usage down as much as
possible.
This patch is unfinished...it solves the main issue, but there is some
corruption in the active_dir_propfinds (which I sort of tried to
address by using serf's allocator; which isn't a normal paradigm for
Subversion). When I get back home today, I need to concentrate on my
pending cross-country move and starting my new position in NYC. So,
it may be a few weeks before I get any real chance to look at this
again.
In the meantime, I know that Greg is planning to rewrite the XML
parsing in update.c to fit the new parsing paradigm that has been
introduced into other parts of ra_serf as well as getting the Propfind
depth:1 in. My guess it that after the parsing rewrite and depth 1 is
complete, this issue may fall by the wayside...or not.
Hence, I'll just throw the current patch on the list for posterity.
When I come up for air again, I'll try to evaluate if it is still
needed. FWIW, Instruments on OS X is awesome. -- justin
Index: subversion/libsvn_ra_serf/update.c
===
--- subversion/libsvn_ra_serf/update.c (revision 1351209)
+++ subversion/libsvn_ra_serf/update.c (working copy)
@@ -48,6 +48,8 @@
#include ra_serf.h
#include ../libsvn_ra/ra_loader.h
+#include serf_bucket_util.h
+
/*
* This enum represents the current state of our XML parsing for a REPORT.
@@ -292,6 +294,7 @@ typedef struct report_fetch_t {
*/
struct report_context_t {
apr_pool_t *pool;
+ serf_bucket_alloc_t *allocator;
svn_ra_serf__session_t *sess;
svn_ra_serf__connection_t *conn;
@@ -348,7 +351,11 @@ struct report_context_t {
/* completed PROPFIND requests (contains svn_ra_serf__handler_t) */
svn_ra_serf__list_t *done_propfinds;
+ svn_ra_serf__list_t *done_dir_propfinds;
+ /* list of outstanding prop changes (contains report_dir_t) */
+ svn_ra_serf__list_t *active_dir_propfinds;
+
/* list of files that only have prop changes (contains report_info_t) */
svn_ra_serf__list_t *file_propchanges_only;
@@ -654,6 +661,7 @@ close_dir(report_dir_t *dir)
}
svn_pool_destroy(dir-dir_baton_pool);
+ printf(destroy: %p (%s)\n, dir-pool, dir-name);
svn_pool_destroy(dir-pool);
return SVN_NO_ERROR;
@@ -1888,6 +1896,7 @@ end_report(svn_ra_serf__xml_parser_t *parser,
*/
if (!SVN_IS_VALID_REVNUM(info-dir-base_rev) || info-dir-fetch_props)
{
+ svn_ra_serf__list_t *list_item;
/* Unconditionally set fetch_props now. */
info-dir-fetch_props = TRUE;
@@ -1897,7 +1906,7 @@ end_report(svn_ra_serf__xml_parser_t *parser,
info-dir-url,
ctx-target_rev, 0,
all_props,
- ctx-done_propfinds,
+ ctx-done_dir_propfinds,
info-dir-pool));
SVN_ERR_ASSERT(info-dir-propfind_handler);
@@ -1906,6 +1915,11 @@ end_report(svn_ra_serf__xml_parser_t *parser,
ctx-active_propfinds++;
+ list_item = serf_bucket_mem_alloc(ctx-allocator,
sizeof(*list_item));
+ list_item-data = info-dir;
+ list_item-next = ctx-active_dir_propfinds;
+ ctx-active_dir_propfinds = list_item;
+
if (ctx-active_fetches + ctx-active_propfinds
REQUEST_COUNT_TO_PAUSE)
ctx-parser_ctx-paused = TRUE;
@@ -2525,12 +2539,77 @@ finish_report(void *report_baton,
}
report-done_propfinds = NULL;
+ done_list = report-done_dir_propfinds;
+ while (done_list)
+{
+ svn_pool_clear(iterpool_inner);
+
+ report-active_propfinds--;
+
+ if (report-active_dir_propfinds)
+{
+ svn_ra_serf__list_t *cur, *prev;
+
+ cur = report-active_dir_propfinds;
+ prev = NULL;
+
+ while (cur)
+{
+ report_dir_t *item = cur-data;
+
+ if (item-propfind_handler == done_list-data)
+{
+ break;
+}
+
+ prev = cur;
+ cur = cur-next;
+}
+ if (cur)
+{
+ report_dir_t *cur_dir = cur-data;
+
+ while (cur_dir !cur_dir-ref_count
Re: Open mailing lists
Darren, Over a dozen sites mirror our archives, usually by grabbing our published mbox for the list. As a result, we cannot control how they publish the email addresses contained within. It is also important for those mboxes to retain the email addresses for archival purposes, and so those third-party systems can allow proper replies (hopefully, only by humans, but as you've discovered... they are not all perfect). Sorry for any inconvenience, but please don't blame us. We do try to respect your privacy in our own web archive system. Cheers, -g On Jun 18, 2012 5:10 AM, s...@feb17.org wrote: Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy, Darren On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin philip.mar...@wandisco.com wrote: s...@feb17.org writes: A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works.It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky. Thanks! Darren
Confusing error message when updating colliding externals
Hi, From the #svn channel just a few minutes ago. The error message clearly is not that helpful for normal users. Should I file an issue for that? 09:45 stummi hi there. I set an external. (svn propedit svn:externals . on the root of the working copy, with the Entry Extern svn://svnserver/externrepo). the extern directory Extern is on version control. But svn update says cannot relocate '.../mainrepo/Extern' as it is not the root of a working copy; try relocating '.../mainrepo' instead 09:46 stummi what does externals have to do with relocate? Or why does svn think i want to relocate anything? 09:47 stummi svn version: svn, Version 1.7.5 (r1336830) 09:47 stummi from the debian repository 10:13 schabi stummi: Was the Extern directory versioned (existing in the working copy) before you added the esternals definition? 10:13 stummi yes 10:13 schabi Then that is the problem. Externals are implemented via nested working copies (having their own .svn dubdirectory)currently. 10:13 stummi schabi, i just got fixed it in this moment. Didn't know the the directory should not exist for an external 10:14 schabi But the error message could be improved in that case... 10:14 stummi yeah, it is a bit confusing Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Connections get not closed
Hello all, I already sent this issue to the users list some days ago, but so far did not get any hints from there. As this unclosed connections are really causing problems for our server, I´m consulting the devlist now also with it. (Sorry for crossposting.) I'm using the svn 1.7.5 SDK on Win32 with VS2005. For some reason every call fetching data from the server opens up it's own socket connection but doesn't close it when data retrieval is finished. I tried this with for the functions svn_client_status4(), svn_client_update4() and svn_client_checkout3(), but I guess the problem is not specific to one or some functions. When examining the sockets in TCPView they are generally listed as 'established', some however even pop out of their host process and live on in the system process (PID:0) as 'waiting' for some time. When closing down the application the remaining connections also go the latter way. This behaviour results in hundreds of open connections (e.g. when checking the status of all files of a project) which is more than the server can/should handle. Please give me any advice if there is a possiblity to close svn connections by function call or by limiting the life span of connections when they are established. Of course I also will appreciate all other hints and ideas. Please CC my e-mailaddress to any replies, as I´m not receiving the dev-list. Kind regards and Thanks in advance Jörn Müller
Re: AW: Shell script to make a log message template
The mail archive at http://svn.haxx.se/dev/archive-2012-06/0164.shtml
presents it a bit better: the attachment is not base-64 encoded, and the
message body is formatted better, but still not properly.
I am attaching the script again now, as plain text. Apologies for attaching it
as 'application/octet-stream' that time.
- Julian
From: Markus Schaber m.scha...@3s-software.com
Its the link labelled svnlogmsg (application/octet-stream) - and it is
base64 encoded, it seems.
Von: Carlos Andrade [carlosvia...@gmail.com]
Yes I was trying to find on that list but it wasn't tied on the reply that I
saw the following message. Is there any specific location that the attachments
are stored? I can't seem to find the attached script there. Sorry for the
trouble and thank you!
On Jun 15, 2012, at 1:24 PM, Markus Schaber m.scha...@3s-software.com wrote:
It's archived, like all
mails on that list:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201206.mbox/%3C1339422092.76206.YahooMailNeo%40web87704.mail.ir2.yahoo.com%3E
Von: Carlos Andrade [carlosvia...@gmail.com]
Dears, could anyone please provide a pointer to the script and the original
email? I am not being able to
locate it.
On Jun 15, 2012, at 1:06 AM, Markus Schaber m.scha...@3s-software.com
wrote:
Von: Stefan Fuhrmann [eq...@web.de]
On 06/11/2012 03:41 PM, Julian Foad wrote:
For anyone interested, attached is the shell script I use to generate a
log message template for a particular svn diff.
[...]
That script is brilliant! I hated writing log messages
but now it's just a ~/svnlogmsg.sh | gedit
It even works when
using cygwin bash and having the native windows svn.exe (sliksvn) in your
path, without any slash vs backslash issues.
Thanks a lot!
Markus Schaber
#!/bin/bash
# Write a Subversion log message template to stdout. List the files that would
# be committed and attempt to list the names of functions changed. (The listing
# of functions is very unreliable.) Add a full diff for review and reference.
# Usage: $0 [dir/file...]
# Get a list of the files (and dirs) affected.
FILES=`svn st $@ | grep -v -E ^(\?| L|X|Performing|DBG:|$) | sed
's/^...//' | sort`
echo
# List the files affected, and attempt to list the functions affected.
for FILE in $FILES; do
echo * $FILE
# Find the names of the functions affected, and list them in parentheses.
# Diff with no context ('-U0') to get more accurate function names.
svn diff --depth=empty --diff-cmd diff -x '-U0 -p' $FILE |
sed -e s/^@@ [^@]* @@ .*\\(\([A-Za-z_][A-Za-z0-9_]*\) *(.*\|struct
\([A-Za-z_][A-Za-z0-9_]*\)$\)/ (\2\3): / -e t -e d |
uniq
echo
done
# Ensure svn doesn't include the diff with the log message when committing.
echo '--This line, and those below, will be ignored--'
echo
# Append the diff. Call 'svn diff' for each file separately, to get them
# in the same order as the list above.
for FILE in $FILES; do
svn diff --depth=empty --diff-cmd diff -x -pu $FILE
done
Re: Confusing error message when updating colliding externals
Yes, I think it's a good idea to at least note this in the issue tracker (makes it at least discoverable by other users running into it). And if you know how to fix it ... that would be even better of course :-). But even only having the issue is useful. -- Johan On Mon, Jun 18, 2012 at 10:21 AM, Markus Schaber m.scha...@3s-software.com wrote: Hi, From the #svn channel just a few minutes ago. The error message clearly is not that helpful for normal users. Should I file an issue for that? 09:45 stummi hi there. I set an external. (svn propedit svn:externals . on the root of the working copy, with the Entry Extern svn://svnserver/externrepo). the extern directory Extern is on version control. But svn update says cannot relocate '.../mainrepo/Extern' as it is not the root of a working copy; try relocating '.../mainrepo' instead 09:46 stummi what does externals have to do with relocate? Or why does svn think i want to relocate anything? 09:47 stummi svn version: svn, Version 1.7.5 (r1336830) 09:47 stummi from the debian repository 10:13 schabi stummi: Was the Extern directory versioned (existing in the working copy) before you added the esternals definition? 10:13 stummi yes 10:13 schabi Then that is the problem. Externals are implemented via nested working copies (having their own .svn dubdirectory)currently. 10:13 stummi schabi, i just got fixed it in this moment. Didn't know the the directory should not exist for an external 10:14 schabi But the error message could be improved in that case... 10:14 stummi yeah, it is a bit confusing Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Open mailing lists
It should also be pointed out that a spammer could easily subscribe directly to the list and get all the address information that way, completely by passing any archives. For completeness, the ASF's public archive policy, which we adhere to, is here: http://www.apache.org/foundation/public-archives.html Best, -Hyrum On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein gst...@gmail.com wrote: Darren, Over a dozen sites mirror our archives, usually by grabbing our published mbox for the list. As a result, we cannot control how they publish the email addresses contained within. It is also important for those mboxes to retain the email addresses for archival purposes, and so those third-party systems can allow proper replies (hopefully, only by humans, but as you've discovered... they are not all perfect). Sorry for any inconvenience, but please don't blame us. We do try to respect your privacy in our own web archive system. Cheers, -g On Jun 18, 2012 5:10 AM, s...@feb17.org wrote: Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy, Darren On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin philip.mar...@wandisco.com wrote: s...@feb17.org writes: A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works. It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky. Thanks! Darren -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: Open mailing lists
On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote: It should also be pointed out that a spammer could easily subscribe directly to the list and get all the address information that way, completely by passing any archives. For completeness, the ASF's public archive policy, which we adhere to, is here: http://www.apache.org/foundation/public-archives.html Best, -Hyrum At least that's a tiny bit more work for them to sign up for every email list serve in the world. Harvesting openly published email addresses is just too easy. They would ideally never appear anywhere in the first place so they couldn't be mirrored. I understand your constrants but I still think this is appalling from an engineering point of view and won't participate if it means leaving a please spam me trail behind me. Sorry, Darren On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein gst...@gmail.com wrote: Darren, Over a dozen sites mirror our archives, usually by grabbing our published mbox for the list. As a result, we cannot control how they publish the email addresses contained within. It is also important for those mboxes to retain the email addresses for archival purposes, and so those third-party systems can allow proper replies (hopefully, only by humans, but as you've discovered... they are not all perfect). Sorry for any inconvenience, but please don't blame us. We do try to respect your privacy in our own web archive system. Cheers, -g On Jun 18, 2012 5:10 AM, s...@feb17.org wrote: Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy, Darren On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin philip.mar...@wandisco.com wrote: s...@feb17.org writes: A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works. It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky. Thanks! Darren -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: Open mailing lists
s...@feb17.org wrote on Mon, Jun 18, 2012 at 07:16:01 -0700: On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote: It should also be pointed out that a spammer could easily subscribe directly to the list and get all the address information that way, completely by passing any archives. For completeness, the ASF's public archive policy, which we adhere to, is here: http://www.apache.org/foundation/public-archives.html Best, -Hyrum At least that's a tiny bit more work for them to sign up for every email list serve in the world. Harvesting openly published email addresses is just too easy. They would ideally never appear anywhere in the first place so they couldn't be mirrored. I understand your constrants but I still think this is appalling from an engineering point of view and won't participate if it means leaving a please spam me trail behind me. Nearly all open-source projects rely on email communications, and most are publicly archived in 1 places. You could use auto-expiring email addresses (for example, address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but pretty useless for spammers. Sorry, Darren On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein gst...@gmail.com wrote: Darren, Over a dozen sites mirror our archives, usually by grabbing our published mbox for the list. As a result, we cannot control how they publish the email addresses contained within. It is also important for those mboxes to retain the email addresses for archival purposes, and so those third-party systems can allow proper replies (hopefully, only by humans, but as you've discovered... they are not all perfect). Sorry for any inconvenience, but please don't blame us. We do try to respect your privacy in our own web archive system. Cheers, -g On Jun 18, 2012 5:10 AM, s...@feb17.org wrote: Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy, Darren On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin philip.mar...@wandisco.com wrote: s...@feb17.org writes: A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works. It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky. Thanks! Darren -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: AW: Shell script to make a log message template
Thank you very much! :) Carlos Andrade http://carlosandrade.co 2012/6/18 Julian Foad julianf...@btopenworld.com The mail archive at http://svn.haxx.se/dev/archive-2012-06/0164.shtml presents it a bit better: the attachment is not base-64 encoded, and the message body is formatted better, but still not properly. I am attaching the script again now, as plain text. Apologies for attaching it as 'application/octet-stream' that time. - Julian -- *From:* Markus Schaber m.scha...@3s-software.com ** Its the link labelled svnlogmsg (application/octet-stream) - and it is base64 encoded, it seems. Von: Carlos Andrade [carlosvia...@gmail.com] Yes I was trying to find on that list but it wasn't tied on the reply that I saw the following message. Is there any specific location that the attachments are stored? I can't seem to find the attached script there. Sorry for the trouble and thank you! On Jun 15, 2012, at 1:24 PM, Markus Schaber m.scha...@3s-software.com wrote: It's archived, like all mails on that list: http://mail-archives.apache.org/mod_mbox/subversion-dev/201206.mbox/%3C1339422092.76206.YahooMailNeo%40web87704.mail.ir2.yahoo.com%3E Von: Carlos Andrade [carlosvia...@gmail.com] Dears, could anyone please provide a pointer to the script and the original email? I am not being able to locate it. On Jun 15, 2012, at 1:06 AM, Markus Schaber m.scha...@3s-software.com wrote: Von: Stefan Fuhrmann [eq...@web.de] On 06/11/2012 03:41 PM, Julian Foad wrote: For anyone interested, attached is the shell script I use to generate a log message template for a particular svn diff. [...] That script is brilliant! I hated writing log messages but now it's just a ~/svnlogmsg.sh | gedit It even works when using cygwin bash and having the native windows svn.exe (sliksvn) in your path, without any slash vs backslash issues. Thanks a lot! Markus Schaber
Re: Open mailing lists
Yes again sorry this is probably the wrong place to opine on this topic. I generally use disposable email addresses but accidentally used a permanent long term address at one point, otherwise I'd just have cut off the bleeding there. I don't think it's easy for everyone to generate lots of disposable addresses. If there's any way of nuking this page, it would be appreciated http://mail-archives.apache.org/mod_mbox/subversion-dev/201203.mbox/raw/%3c20120314050552.gm5...@clowder.feb17.org%3E It doesn't appear to have been replicated yet. I'm really sorry to disrupt the svn discussion. I've joined two open source mailing lists and been spammed as a result 100% of the time, so it's buyer beware. I think it would be wonderful if someone looked at the list serve infrastructure and made it safer. This feels like telnet circa 1995, Adieu and thanks for listening, Darren Nearly all open-source projects rely on email communications, and most are publicly archived in 1 places. You could use auto-expiring email addresses (for example, address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but pretty useless for spammers. Sorry, Darren On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein gst...@gmail.com wrote: Darren, Over a dozen sites mirror our archives, usually by grabbing our published mbox for the list. As a result, we cannot control how they publish the email addresses contained within. It is also important for those mboxes to retain the email addresses for archival purposes, and so those third-party systems can allow proper replies (hopefully, only by humans, but as you've discovered... they are not all perfect). Sorry for any inconvenience, but please don't blame us. We do try to respect your privacy in our own web archive system. Cheers, -g On Jun 18, 2012 5:10 AM, s...@feb17.org wrote: Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy, Darren On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin philip.mar...@wandisco.com wrote: s...@feb17.org writes: A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with Thanks to everyone who contributed useful clues on this. Using the current code tree and rebuilding with different versions and combinations of libraries I narrowed the problem down to the apr version. Either the build of my earlier apr 1.3.9 or the version itself was the problem. The test suite was super helpful and the explanation about XFAIL vs FAIL. I have a build using apr 1.4.6 that passes all the tests it should pass and more importantly actually works. It might be helpful to print a reminder at the end of the default make step suggesting running the tests if this is a common problem. There are a lot of dependencies and some of them seem to be a bit finicky. Thanks! Darren -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: svn delete fails with 403 Forbidden if root is not readable
Hello again, I've fixed the issue in SVNKit: http://svn.svnkit.com/repos/svnkit/trunk/ at r9286 The approach is to use common ancestor instead of repository root to run editor calls. For example, to remove paths: directory/subdirectory1/file1 directory/subdirectory1/file2 directory/subdirectory2/file3 instead of running openRoot(); opedDir(directory) opedDir(directory/subdirectory1) delete(directory/subdirectory1/file1) delete(directory/subdirectory1/file2) closeDir() opedDir(directory/subdirectory2) delete(directory/subdirectory1/file3) closeDir() closeDir() closeDir() on http://host/path as on the root one can run opedRoot() opedDir(subdirectory1) delete(subdirectory1/file1) delete(subdirectory1/file2) closeDir() opedDir(subdirectory2) delete(subdirectory1/file3) closeDir() closeDir() http://host/path/directory as on the common ancestor. Hello, Suppose you have a repository with authz: [/] * = [/directory] * = rw And the repository (http://localhost:43714/repos) contains a directory (with rw access) and a file in it. File deletion fails with the following stacktrace (tried with SVN r1350986): $ svn rm http://localhost:43714/repos/directory/file --username user --password password -m subversion/svn/delete-cmd.c:90: (apr_err=130003) subversion/svn/util.c:913: (apr_err=130003) subversion/libsvn_client/delete.c:409: (apr_err=130003) subversion/libsvn_client/delete.c:315: (apr_err=130003) subversion/libsvn_client/delete.c:217: (apr_err=130003) subversion/libsvn_delta/deprecated.c:52: (apr_err=130003) subversion/libsvn_delta/path_driver.c:169: (apr_err=130003) subversion/libsvn_ra_serf/commit.c:1300: (apr_err=130003) subversion/libsvn_ra_serf/options.c:381: (apr_err=130003) subversion/libsvn_ra_serf/util.c:780: (apr_err=130003) subversion/libsvn_ra_serf/util.c:737: (apr_err=130003) subversion/libsvn_ra_serf/util.c:1980: (apr_err=130003) subversion/libsvn_ra_serf/util.c:1961: (apr_err=130003) subversion/libsvn_ra_serf/util.c:2418: (apr_err=130003) svn: E130003: The OPTIONS response contains invalid XML (403 Forbidden) With SVN 1.6 everything is ok. The problem is easily reproducible.
crash in svn_client_url_from_path2
Hi, There's an access violation happening in svn_client_url_from_path2(). Stacktrace attached. Seems there's a situation where work_del_relpath can be NULL. Can't figure out however what that situation exactly is. Crash dump available here: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=1192 Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net libsvn_tsvn.dll!svn_relpath_dirname(const char * relpath=0x, apr_pool_t * pool=0x) Line 1238C libsvn_tsvn.dll!read_url_txn(void * baton=0x05c7eb50, svn_wc__db_wcroot_t * wcroot=0x, const char * local_relpath=0x, apr_pool_t * scratch_pool=0x) Line 7419 C libsvn_tsvn.dll!svn_sqlite__with_lock(svn_sqlite__db_t * db=0x, svn_error_t * (void *, svn_sqlite__db_t *, apr_pool_t *) * cb_func=0x05c7ec28, void * cb_baton=0x, apr_pool_t * scratch_pool=0x) Line 1117 C libsvn_tsvn.dll!svn_wc__db_with_txn(svn_wc__db_wcroot_t * wcroot=0x05c7eb40, const char * local_relpath=0x05c7eb48, svn_error_t * (void *, svn_wc__db_wcroot_t *, const char *, apr_pool_t *) * cb_func=0x, void * cb_baton=0x, apr_pool_t * scratch_pool=0x) Line 203 C libsvn_tsvn.dll!svn_wc__db_read_url(const char * * url=0x, svn_wc__db_t * db=0x, const char * local_abspath=0x05c7ec28, apr_pool_t * result_pool=0x, apr_pool_t * scratch_pool=0x) Line 7502C libsvn_tsvn.dll!svn_wc__node_get_url(const char * * url=0x, svn_wc_context_t * wc_ctx=0x, const char * local_abspath=0x05c7ec28, apr_pool_t * result_pool=0x, apr_pool_t * scratch_pool=0x) Line 356C libsvn_tsvn.dll!svn_client_url_from_path2(const char * * url=0x, const char * path_or_url=0x, svn_client_ctx_t * ctx=0x05c7ec40, apr_pool_t * result_pool=0x, apr_pool_t * scratch_pool=0x) Line 57 C
[PATCH]: Add 'replaced' value to ConflictDescriptor.Reason
Hi, enum svn_wc_conflict_reason_t has 10 possible values but ConflictDescriptor.Reason from javahl only 6; as I understand this is because some of svn_wc_conflict_reason_t values are experimental (for 1.8); but anyway at least 1 of those values is released (svn_wc_conflict_reason_replaced that is for 1.7). So a corresponding value should be added to javahl. If you accept this patch, I would also ask you to backport it to branches/1.7.x. [[[ Add missing 'replace' value to ConflictDescriptor.Reason enum corresponding to svn_wc_conflict_reason_replaced. * subversion/bindings/javahl/src/org/apache/subversion/javahl/ConflictDescriptor.java (Reason): Add 'replace' value. ]]] [[[ Index: subversion/bindings/javahl/src/org/apache/subversion/javahl/ConflictDescriptor.java === --- subversion/bindings/javahl/src/org/apache/subversion/javahl/ConflictDescriptor.java (revision 1351459) +++ subversion/bindings/javahl/src/org/apache/subversion/javahl/ConflictDescriptor.java (working copy) @@ -241,6 +241,11 @@ public class ConflictDescriptor * Object is already added or schedule-add. */ added; + +/** + * Object is already replaced. + */ +replaced; } public enum Operation ]]]
Re: crash in svn_client_url_from_path2
I think it's a bug to pass url=NULL to svn_client_url_from_path2(). Are you saying there is another bug here? Stefan Küng wrote on Mon, Jun 18, 2012 at 21:04:53 +0200: Hi, There's an access violation happening in svn_client_url_from_path2(). Stacktrace attached. Seems there's a situation where work_del_relpath can be NULL. Can't figure out however what that situation exactly is. Crash dump available here: https://www.crash-server.com/Problem.aspx?ClientID=tsvnProblemID=1192 Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net libsvn_tsvn.dll!svn_relpath_dirname(const char * relpath=0x, apr_pool_t * pool=0x) Line 1238 C libsvn_tsvn.dll!read_url_txn(void * baton=0x05c7eb50, svn_wc__db_wcroot_t * wcroot=0x, const char * local_relpath=0x, apr_pool_t * scratch_pool=0x) Line 7419 C libsvn_tsvn.dll!svn_sqlite__with_lock(svn_sqlite__db_t * db=0x, svn_error_t * (void *, svn_sqlite__db_t *, apr_pool_t *) * cb_func=0x05c7ec28, void * cb_baton=0x, apr_pool_t * scratch_pool=0x) Line 1117 C libsvn_tsvn.dll!svn_wc__db_with_txn(svn_wc__db_wcroot_t * wcroot=0x05c7eb40, const char * local_relpath=0x05c7eb48, svn_error_t * (void *, svn_wc__db_wcroot_t *, const char *, apr_pool_t *) * cb_func=0x, void * cb_baton=0x, apr_pool_t * scratch_pool=0x) Line 203 C libsvn_tsvn.dll!svn_wc__db_read_url(const char * * url=0x, svn_wc__db_t * db=0x, const char * local_abspath=0x05c7ec28, apr_pool_t * result_pool=0x, apr_pool_t * scratch_pool=0x) Line 7502C libsvn_tsvn.dll!svn_wc__node_get_url(const char * * url=0x, svn_wc_context_t * wc_ctx=0x, const char * local_abspath=0x05c7ec28, apr_pool_t * result_pool=0x, apr_pool_t * scratch_pool=0x) Line 356C libsvn_tsvn.dll!svn_client_url_from_path2(const char * * url=0x, const char * path_or_url=0x, svn_client_ctx_t * ctx=0x05c7ec40, apr_pool_t * result_pool=0x, apr_pool_t * scratch_pool=0x) Line 57 C
Re: crash in svn_client_url_from_path2
On 18.06.2012 21:37, Daniel Shahaf wrote: I think it's a bug to pass url=NULL to svn_client_url_from_path2(). Are you saying there is another bug here? I never pass NULL. Even if the call to svn_dirent_canonicalize() would return NULL I still pass an empty string in that situation. Stack traces aren't always reliable what the shown data really is. But the exception code is (access violation) and the position where that happens. From there you have to go backwards, but the further backwards you go the more likely it is that the parameters shown in the stack trace are not the real ones anymore. Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: Connections get not closed
On Mon, Jun 18, 2012 at 10:40:49AM +0200, Joern Mueller wrote: Hello all, I already sent this issue to the users list some days ago, but so far did not get any hints from there. As this unclosed connections are really causing problems for our server, I´m consulting the devlist now also with it. (Sorry for crossposting.) I'm using the svn 1.7.5 SDK on Win32 with VS2005. For some reason every call fetching data from the server opens up it's own socket connection but doesn't close it when data retrieval is finished. I tried this with for the functions svn_client_status4(), svn_client_update4() and svn_client_checkout3(), but I guess the problem is not specific to one or some functions. When examining the sockets in TCPView they are generally listed as 'established', some however even pop out of their host process and live on in the system process (PID:0) as 'waiting' for some time. When closing down the application the remaining connections also go the latter way. This behaviour results in hundreds of open connections (e.g. when checking the status of all files of a project) which is more than the server can/should handle. Please give me any advice if there is a possiblity to close svn connections by function call or by limiting the life span of connections when they are established. Of course I also will appreciate all other hints and ideas. Please CC my e-mailaddress to any replies, as I´m not receiving the dev-list. Kind regards and Thanks in advance Jörn Müller Hi Jörn, have you tried clearing (with svn_pool_clear()) or even destroying (with svn_pool_destroy()) pools passed to the svn_client_* functions? That should close sockets and also free other resource (temporary allocations, file descriptors, etc.). You can clear a scratch_pool right after each call, and a result_pool (if any) once you don't need the results anymore.
incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5
I've upgraded Subversion from 1.6.17 to 1.7.5 (Debian/unstable). And there's the following problem: Subversion 1.7.5 no longer notices a change of revision of some file when a parent directory has been moved. In particular, this yields incorrect keyword expansion. The bug can be reproduced with the following script: #!/bin/sh set -e mkdir my-test-svn cd my-test-svn svnadmin create svn svn co file://`pwd`/svn wc cd wc svn mkdir dir1 svn ci -m 'add dir1' printf '\044Revision\044\nfoo\n' dir1/file svn add dir1/file svn propset svn:keywords Revision dir1/file svn ci -m 'add dir1/file' echo File dir1/file: cat dir1/file svn up svn mv dir1 dir2 echo File dir2/file: cat dir2/file svn ci -m 'mv dir1 dir2' echo File dir2/file: cat dir2/file svn up echo File dir2/file: cat dir2/file svn info dir2/file svn mv dir2/file . echo File file: cat file svn ci -m 'mv dir2/file .' echo File file: cat file cd ../.. rm -rf my-test-svn If I grep the output with '.Revision:\|Last Changed Rev:', I get: * svn 1.6.17 (r1128011): 2 2 3 3 3 -1 4 * svn 1.7.5 (r1336830): 2 2 2 2 2 2 4 There are 4 differences, but only 3 really matter, because for the last one (-1 vs 2), the commit hasn't been done yet (so that one is in some intermediate state). Thus the important differences (3 vs 2) correspond to: svn ci -m 'mv dir1 dir2' echo File dir2/file: cat dir2/file svn up echo File dir2/file: cat dir2/file svn info dir2/file The last test of the script shows that the problem doesn't occur when the file itself is moved. Because of that, when checking out a repository with svn 1.7.5, some files seem to go back in time. FYI, my bug report in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678075 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: incorrect Last Changed Rev after upgrade from 1.6.17 to 1.7.5
In 1.6, we erroneously used the containing directory's revision for the file in certain cases. 1.7 is correct: the file is not changed until r4. Maybe the directory has, but that is independent of the file. Cheers, -g On Jun 19, 2012 3:02 AM, Vincent Lefevre vincent-...@vinc17.net wrote: I've upgraded Subversion from 1.6.17 to 1.7.5 (Debian/unstable). And there's the following problem: Subversion 1.7.5 no longer notices a change of revision of some file when a parent directory has been moved. In particular, this yields incorrect keyword expansion. The bug can be reproduced with the following script: #!/bin/sh set -e mkdir my-test-svn cd my-test-svn svnadmin create svn svn co file://`pwd`/svn wc cd wc svn mkdir dir1 svn ci -m 'add dir1' printf '\044Revision\044\nfoo\n' dir1/file svn add dir1/file svn propset svn:keywords Revision dir1/file svn ci -m 'add dir1/file' echo File dir1/file: cat dir1/file svn up svn mv dir1 dir2 echo File dir2/file: cat dir2/file svn ci -m 'mv dir1 dir2' echo File dir2/file: cat dir2/file svn up echo File dir2/file: cat dir2/file svn info dir2/file svn mv dir2/file . echo File file: cat file svn ci -m 'mv dir2/file .' echo File file: cat file cd ../.. rm -rf my-test-svn If I grep the output with '.Revision:\|Last Changed Rev:', I get: * svn 1.6.17 (r1128011): 2 2 3 3 3 -1 4 * svn 1.7.5 (r1336830): 2 2 2 2 2 2 4 There are 4 differences, but only 3 really matter, because for the last one (-1 vs 2), the commit hasn't been done yet (so that one is in some intermediate state). Thus the important differences (3 vs 2) correspond to: svn ci -m 'mv dir1 dir2' echo File dir2/file: cat dir2/file svn up echo File dir2/file: cat dir2/file svn info dir2/file The last test of the script shows that the problem doesn't occur when the file itself is moved. Because of that, when checking out a repository with svn 1.7.5, some files seem to go back in time. FYI, my bug report in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678075 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
