Re: svn commit: r1407279 - in /subversion/trunk/subversion: svnadmin/main.c tests/cmdline/svntest/main.py
On 8 November 2012 23:07, Stefan Sperling s...@elego.de wrote: 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! :) Hmm, I just tried to look at this diff in the source viewer at svn.apache.org because I am not subscribed to the commits list, but it seems to crash. Does anyone else see a stack trace instead of a diff? http://svn.apache.org/viewvc/subversion/trunk/subversion/svnadmin/main.c?r1=1407279r2=1407278pathrev=1407279 -- Mat Booth Software Engineer WANdisco, Inc. http://www.wandisco.com
Windows buildbot FAIL on 1.7.x
The Windows buildbots are failing on the 1.7.x branch: FAIL: patch_tests.py 37: patch target with no eol at eof @@ -1,2 +1,2 @@ -U svn-test-work\working_copies\patch_tests-37\A/mu +U svn-test-work\working_copies\patch_tests-37\A\mu U svn-test-work\working_copies\patch_tests-37\iota CWD: E:\w2k3\tests\subversion\tests\cmdline EXCEPTION: SVNLineUnequal The problem is the wrong separator in the path for the patch notification. This test is a PASS on trunk and I can't spot a difference in the test code so it appears to be a problem in the client. -- 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
Mat Booth wrote on Fri, Nov 09, 2012 at 10:07:25 +: On 8 November 2012 23:07, Stefan Sperling s...@elego.de wrote: 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! :) Hmm, I just tried to look at this diff in the source viewer at svn.apache.org because I am not subscribed to the commits list, but it seems to crash. Does anyone else see a stack trace instead of a diff? Fixed. Something broke when we upgraded viewvc on svn.eu http://svn.apache.org/viewvc/subversion/trunk/subversion/svnadmin/main.c?r1=1407279r2=1407278pathrev=1407279 -- Mat Booth Software Engineer WANdisco, Inc. http://www.wandisco.com
Re: [RFC] Non-normalizing Unicode Composition Awareness
Revisiting this thread after a few months. Last spring, I did some work in the Wiki designing a proposal for resolving the Mac Unicode issues in a Non-normalizing manner. I ran out of time, but the thought process has been ongoing. A couple of weeks ago at Subversion Live in London, I had the opportunity to discuss with a number of people. Although there were some different opinions on the matter, I think we concluded that we are actually relatively well aligned on the core idea. The proposal I drafted this spring (in the Wiki) proposed that a couple of columns were added to the WC in order to store normalized paths. Since a couple of months the concept of using a Sqlite collation has seemed more appealing. Last week, I did a test with the Sqlite ICU extension (available in sqlite source repository) which turned out to be quite encouraging. With such a collation, it is possible to perform equals in SQL statements that match paths in a Unicode composition aware manner and therefore return rows regardless what composition the paths have. This would be very useful, for instance, when given a filesystem path attempting to locate the corresponding node in wc.db. That is basically half the issue with Mac working copies. Today, I noticed that Branko started some implementation in a branch. Looks like a collation based on utf8proc is in the making? I think that would make a lot of sense because the ICU extension poses some challenges in the build process and we might not need all that functionality that it provides. I started a wiki page about unicode collation. I will append more info: http://wiki.apache.org/subversion/UnicodeCollation Also note the tiny test repo attached to: http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness Cheers, Thomas Å.
Re: Windows buildbot FAIL on 1.7.x
On Fri, Nov 09, 2012 at 11:07:33AM +, Philip Martin wrote: The Windows buildbots are failing on the 1.7.x branch: FAIL: patch_tests.py 37: patch target with no eol at eof @@ -1,2 +1,2 @@ -U svn-test-work\working_copies\patch_tests-37\A/mu +U svn-test-work\working_copies\patch_tests-37\A\mu U svn-test-work\working_copies\patch_tests-37\iota CWD: E:\w2k3\tests\subversion\tests\cmdline EXCEPTION: SVNLineUnequal The problem is the wrong separator in the path for the patch notification. This test is a PASS on trunk and I can't spot a difference in the test code so it appears to be a problem in the client. It's likely this bug in the test which I introduced on the backport branch in r1399178. Can I just commit that to the 1.7.x branch as obvious fix? Index: subversion/tests/cmdline/patch_tests.py === --- subversion/tests/cmdline/patch_tests.py (revision 1407431) +++ subversion/tests/cmdline/patch_tests.py (working copy) @@ -3939,7 +3939,7 @@ def patch_target_no_eol_at_eof(sbox): context, # no newline at end of file ] expected_output = [ -'U %s\n' % os.path.join(wc_dir, 'A/mu'), +'U %s\n' % os.path.join(wc_dir, 'A', 'mu'), 'U %s\n' % os.path.join(wc_dir, 'iota'), ]
Re: [RFC] Non-normalizing Unicode Composition Awareness
On 09.11.2012 12:28, Thomas Åkesson wrote: Today, I noticed that Branko started some implementation in a branch. Looks like a collation based on utf8proc is in the making? I think that would make a lot of sense because the ICU extension poses some challenges in the build process and we might not need all that functionality that it provides. Hi Thomas, Yes, I started a branch that's intended to fix the normalization problem. I selected utf8proc because we really don't need ICU (I can't see a serious need for language-specific case folding, for example, nor for Unicode regular expressions). Furthermore, utf8proc can be easily embedded into Subversion so it doesn't present another dependency that users would have to worry about. I'm currently doing the grunt work of implementing the collation (done) and the LIKE and GLOB operators that we'll need (in progress). The next, and biggest, step will be to review the client and WC libraries to make sure that paths sent to the server always come from the wc.db, not from disk. One open question is what to do about (historical) collisions in existing repositories, but I don't think that issue is important enough to resolve now. It'll take a while, but I hope to be able to finish the work in time for 1.8. If not ... well then, it'll be in 1.9. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Windows buildbot FAIL on 1.7.x
On 09.11.2012 13:29, Stefan Sperling wrote: On Fri, Nov 09, 2012 at 11:07:33AM +, Philip Martin wrote: The Windows buildbots are failing on the 1.7.x branch: FAIL: patch_tests.py 37: patch target with no eol at eof @@ -1,2 +1,2 @@ -U svn-test-work\working_copies\patch_tests-37\A/mu +U svn-test-work\working_copies\patch_tests-37\A\mu U svn-test-work\working_copies\patch_tests-37\iota CWD: E:\w2k3\tests\subversion\tests\cmdline EXCEPTION: SVNLineUnequal The problem is the wrong separator in the path for the patch notification. This test is a PASS on trunk and I can't spot a difference in the test code so it appears to be a problem in the client. It's likely this bug in the test which I introduced on the backport branch in r1399178. Can I just commit that to the 1.7.x branch as obvious fix? Index: subversion/tests/cmdline/patch_tests.py === --- subversion/tests/cmdline/patch_tests.py (revision 1407431) +++ subversion/tests/cmdline/patch_tests.py (working copy) @@ -3939,7 +3939,7 @@ def patch_target_no_eol_at_eof(sbox): context, # no newline at end of file ] expected_output = [ -'U %s\n' % os.path.join(wc_dir, 'A/mu'), +'U %s\n' % os.path.join(wc_dir, 'A', 'mu'), 'U %s\n' % os.path.join(wc_dir, 'iota'), ] +1 -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Windows buildbot FAIL on 1.7.x
Stefan Sperling s...@elego.de writes: On Fri, Nov 09, 2012 at 11:07:33AM +, Philip Martin wrote: The Windows buildbots are failing on the 1.7.x branch: FAIL: patch_tests.py 37: patch target with no eol at eof @@ -1,2 +1,2 @@ -U svn-test-work\working_copies\patch_tests-37\A/mu +U svn-test-work\working_copies\patch_tests-37\A\mu U svn-test-work\working_copies\patch_tests-37\iota CWD: E:\w2k3\tests\subversion\tests\cmdline EXCEPTION: SVNLineUnequal The problem is the wrong separator in the path for the patch notification. This test is a PASS on trunk and I can't spot a difference in the test code so it appears to be a problem in the client. It's likely this bug in the test which I introduced on the backport branch in r1399178. Can I just commit that to the 1.7.x branch as obvious fix? Index: subversion/tests/cmdline/patch_tests.py === --- subversion/tests/cmdline/patch_tests.py (revision 1407431) +++ subversion/tests/cmdline/patch_tests.py (working copy) @@ -3939,7 +3939,7 @@ def patch_target_no_eol_at_eof(sbox): context, # no newline at end of file ] expected_output = [ -'U %s\n' % os.path.join(wc_dir, 'A/mu'), +'U %s\n' % os.path.join(wc_dir, 'A', 'mu'), 'U %s\n' % os.path.join(wc_dir, 'iota'), ] The same code, without the above patch, seems to PASS on trunk. Why does the branch need different code? Does the testsuite have some path normalisation that corrects/hides the bug? If that patch is the correct solution I think you should commit to trunk and backport. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Windows buildbot FAIL on 1.7.x
Philip Martin philip.mar...@wandisco.com writes: Stefan Sperling s...@elego.de writes: Can I just commit that to the 1.7.x branch as obvious fix? Index: subversion/tests/cmdline/patch_tests.py === --- subversion/tests/cmdline/patch_tests.py (revision 1407431) +++ subversion/tests/cmdline/patch_tests.py (working copy) @@ -3939,7 +3939,7 @@ def patch_target_no_eol_at_eof(sbox): context, # no newline at end of file ] expected_output = [ -'U %s\n' % os.path.join(wc_dir, 'A/mu'), +'U %s\n' % os.path.join(wc_dir, 'A', 'mu'), 'U %s\n' % os.path.join(wc_dir, 'iota'), ] The same code, without the above patch, seems to PASS on trunk. Why does the branch need different code? Does the testsuite have some path normalisation that corrects/hides the bug? If that patch is the correct solution I think you should commit to trunk and backport. Ah! trunk uses the sbox.ospath which handles foo/bar on Windows, I didn't spot that when I compared the code. So we could fix it with your patch above or by switching to sbox.ospath to make the code look like trunk. -- Philip
Re: svn commit: r1311476 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c
On Mon, Apr 09, 2012 at 09:46:34PM -, stef...@apache.org wrote: Author: stefan2 Date: Mon Apr 9 21:46:34 2012 New Revision: 1311476 URL: http://svn.apache.org/viewvc?rev=1311476view=rev Log: Turn hard-coded deltification parameters into config parameters for format 4 and later (they all keep compatibility with 1.6 and 1.7). I just came accross this snippet in the config: +### The following parameter enables deltification for properties on files NL +### and directories. Overall, this is a minor tuning option but can save NL +### some disk space if frequently merge or if you frequently change node NL +### properties. You should not activate this if rep-sharing has been NL +### disabled. NL +### property deltification is disabled by default. NL +# CONFIG_OPTION_ENABLE_PROPS_DELTIFICATION = true NL I don't like the sound of You should not active this if... This sounds as if we're relying on users to keep their configuration files consistent to get proper behaviour, which I hope isn't the case! What happens if this option is activated anyway? Will the user be left with a corrupt repository, or will the option have no effect, or something else? I haven't checked the code. Maybe the configuration file comment just uses misleading wording? I think this should rather say something like You cannot activate this if ... or This option has no effect unless With appropriate implementation behaviour to back these claims up, of course.
Re: Windows buildbot FAIL on 1.7.x
On Fri, Nov 09, 2012 at 01:01:48PM +, Philip Martin wrote: Philip Martin philip.mar...@wandisco.com writes: Stefan Sperling s...@elego.de writes: Can I just commit that to the 1.7.x branch as obvious fix? Index: subversion/tests/cmdline/patch_tests.py === --- subversion/tests/cmdline/patch_tests.py(revision 1407431) +++ subversion/tests/cmdline/patch_tests.py(working copy) @@ -3939,7 +3939,7 @@ def patch_target_no_eol_at_eof(sbox): context, # no newline at end of file ] expected_output = [ -'U %s\n' % os.path.join(wc_dir, 'A/mu'), +'U %s\n' % os.path.join(wc_dir, 'A', 'mu'), 'U %s\n' % os.path.join(wc_dir, 'iota'), ] The same code, without the above patch, seems to PASS on trunk. Why does the branch need different code? Does the testsuite have some path normalisation that corrects/hides the bug? If that patch is the correct solution I think you should commit to trunk and backport. Ah! trunk uses the sbox.ospath which handles foo/bar on Windows, I didn't spot that when I compared the code. So we could fix it with your patch above or by switching to sbox.ospath to make the code look like trunk. Yes. This backport change was made because of a text conflict that happened because gstein switched almost the entire test suite to use sbox.ospath() on trunk. Whether to patch it to use sbox.ospath() or keep using os.path.join() can be argued either way. It doesn't matter. I'd prefer to just commit this little patch. I wouldn't want to have mixed use of sbox.ospath() and os.path.join() idioms in a single test, and switching the entire test over to sbox.ospath() is additional and unnecessary work. Anyway, this shows that switching to os.ospath() on trunk was a good thing because it avoids this kind of mistake in the first place :)
Re: Windows buildbot FAIL on 1.7.x
Stefan Sperling s...@elego.de writes: I'd prefer to just commit this little patch. +1 -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: [RFC] Non-normalizing Unicode Composition Awareness
On 11/09/2012 07:49 AM, Branko Čibej wrote: On 09.11.2012 12:28, Thomas Åkesson wrote: I'm currently doing the grunt work of implementing the collation (done) and the LIKE and GLOB operators that we'll need (in progress). The next, and biggest, step will be to review the client and WC libraries to make sure that paths sent to the server always come from the wc.db, not from disk. I'm not closely following this problem or solution, but how does the above play out for svn import, svn mkdir IRI, svn delete IRI, etc? (If this is documented somewhere, a reference by way of response would suffice.) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [RFC] Non-normalizing Unicode Composition Awareness
On 09.11.2012 14:28, C. Michael Pilato wrote: On 11/09/2012 07:49 AM, Branko Čibej wrote: On 09.11.2012 12:28, Thomas Åkesson wrote: I'm currently doing the grunt work of implementing the collation (done) and the LIKE and GLOB operators that we'll need (in progress). The next, and biggest, step will be to review the client and WC libraries to make sure that paths sent to the server always come from the wc.db, not from disk. I'm not closely following this problem or solution, but how does the above play out for svn import, svn mkdir IRI, svn delete IRI, etc? (If this is documented somewhere, a reference by way of response would suffice.) Since these are server-side operations with no working copy involvement, and I'm doing this strictly client-side for now, nothing would change. This is a problem that we'll eventually have to solve on the server as well. I don't believe it would be correct for the client to verify that such operations do not create normalization conflicts on the server. As a matter of interest, a server-side solution is one of the features we identified for FSv2; although there's no reason to wait for that. In FSv2, I envision all names being stored twice, once in their original form, and once NFC-normalized, for indexing. The reason for that is that I expect server CPU cycles to be more expensive than server storage, and it therefore makes sense to avoid using a relatively expensive normalizing collation in the server metadata index. This /may/ turn out to be an issue for client working copy performance, too; but for now I've elected to assume that collation won't have a noticeable effect. If it does, we'll look at other solutions. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: [PATCH]: Encoding fix mailer.py
On 09/04/2012 12:58 PM, Igor Galić wrote: Hey folks, I've patched up my local mailer.py[1] to correctly encode From: Headers. The attached patch *works* but it's not pretty. Someone who actually knows Python might want to encapsulate my changes in a function. n.b.: I am not subscribed to this ML, if you want notify me of updates, please CC me. So long, i [1] http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/mailer/mailer.py Igor, I took a look at your patch. I was confused by one aspect: why split the from_addr into words an encode each one individually, rather than encoding the whole header value like we do for the Subject: header? I dug around in the related RFCs, and if I'm reading the RFCs correctly, doing per-word encoding is actually the right thing to do. Should we, then, do the same for the Subject: header? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: [PATCH]: Encoding fix mailer.py
On 11/09/2012 09:31 AM, C. Michael Pilato wrote:
On 09/04/2012 12:58 PM, Igor Galić wrote:
Hey folks,
I've patched up my local mailer.py[1] to correctly encode
From: Headers.
The attached patch *works* but it's not pretty.
Someone who actually knows Python might want to encapsulate
my changes in a function.
n.b.: I am not subscribed to this ML, if you want notify me
of updates, please CC me.
So long,
i
[1]
http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/mailer/mailer.py
Igor, I took a look at your patch. I was confused by one aspect: why split
the from_addr into words an encode each one individually, rather than
encoding the whole header value like we do for the Subject: header? I dug
around in the related RFCs, and if I'm reading the RFCs correctly, doing
per-word encoding is actually the right thing to do. Should we, then, do
the same for the Subject: header?
Attaching my current modification of your original patch.
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
* tools/hook-scripts/mailer/mailer.py
(MailedOutput.mail_headers): Modularize the code which encodes
header value tokens, and use it for encoding both the Subject: and
From: lines as necessary.
Index: tools/hook-scripts/mailer/mailer.py
===
--- tools/hook-scripts/mailer/mailer.py (revision 1407458)
+++ tools/hook-scripts/mailer/mailer.py (working copy)
@@ -228,12 +228,18 @@
self.reply_to = self.reply_to[3:]
def mail_headers(self, group, params):
-subject = self.make_subject(group, params)
-try:
- subject.encode('ascii')
-except UnicodeError:
- from email.Header import Header
- subject = Header(subject, 'utf-8').encode()
+
+def _maybe_encode_header(hdr):
+ try:
+hdr.encode('ascii')
+return hdr
+ except UnicodeError:
+from email.Header import Header
+return Header(hdr, 'utf-8').encode()
+
+subject = ' '.join(map(_maybe_encode_header,
+ self.make_subject(group, params).split()))
+from_hdr = ' '.join(map(_maybe_encode_header, self.from_addr.split()))
hdrs = 'From: %s\n'\
'To: %s\n' \
'Subject: %s\n' \
@@ -244,7 +250,7 @@
'X-Svn-Commit-Author: %s\n' \
'X-Svn-Commit-Revision: %d\n' \
'X-Svn-Commit-Repository: %s\n' \
- % (self.from_addr, ', '.join(self.to_addrs), subject,
+ % (from_hdr, ', '.join(self.to_addrs), subject,
group, self.repos.author or 'no_author', self.repos.rev,
os.path.basename(self.repos.repos_dir))
if self.reply_to:
signature.asc
Description: OpenPGP digital signature
No Apache httpd for Windows?
I know many of you are part of the httpd project, and I am not, so asking here. With the current Apache 2.2.x and 2.4.x there are no more Windows downloads available. Does anyone know why? I do not see anything on the mailing lists, but maybe I am just missing it. I can understand that maybe whoever was building the Win32 binaries stopped, or did not have time, but I am actually talking about the source code. There is no Win32 zip file as there always has been in the past. And there are no notes that say you should use the Unix tar to build. I was under the impression in the past, that the process of producing the Windows source zip file produced some extra content that was needed to do a build. That said, the docs do not specifically say anything about what source to download. Did they stop posting the Windows zip file because it just is not needed, or is something going on? I am dealing with some weirdness that only happens on Windows, and did not happen with 2.2.22, so want to be sure it is not because I am building with the wrong source. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Content-Length in HEAD responses
On 11/08/2012 11:42 AM, Daniel Shahaf wrote: 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()) To date, I find myself unable through code inspection to see where we do anything about HEAD requests. mod_dav itself doesn't explicitly handle that request, so I'm wondering ... does Apache just handle a HEAD as a GET under-the-hood and then discard the resulting response body? The comment above the #defines for request types in httpd.h leads me to believe this is likely: [...] * These constants are used in bit shifting masks of size int, so it is * unsafe to have more methods than bits in an int. HEAD == M_GET. [...] -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svn commit: r1407279 - in /subversion/trunk/subversion: svnadmin/main.c tests/cmdline/svntest/main.py
On 9 November 2012 11:13, Daniel Shahaf d...@daniel.shahaf.name wrote: Mat Booth wrote on Fri, Nov 09, 2012 at 10:07:25 +: On 8 November 2012 23:07, Stefan Sperling s...@elego.de wrote: 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! :) Hmm, I just tried to look at this diff in the source viewer at svn.apache.org because I am not subscribed to the commits list, but it seems to crash. Does anyone else see a stack trace instead of a diff? Fixed. Something broke when we upgraded viewvc on svn.eu Nice one, thanks. -- Mat Booth Software Engineer WANdisco, Inc. http://www.wandisco.com
Re: Authz on Collection of Repositories
On Thu, Nov 8, 2012 at 6:49 PM, Thomas Åkesson thomas.akes...@simonsoft.se wrote: On 5 nov 2012, at 00:21, Thomas Åkesson wrote: Hi Thomas, Thank you for comprehensive testing! See my reply inline. 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. That's why mixing anonymous and authenticated access is not good thing. - 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?!? I agree, this is really strange behavior. Could you check this behavior with my patch? It's very low chance that my patch changes this behavior. 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. Good. 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. It would be nice if you confirm that my patch does not change AuthzSVNAnonymous Off behavior in this case I'll commit my patch and we may focus on this issue. -- Ivan Zhakov
serf buildbot FAIL on trunk@1407545
The centos buildbot failed on trunk@1407545. I can't reproduce it. The
failing update produces:
U svn-test-work/working_copies/special_tests-25/s-type
Usvn-test-work/working_copies/special_tests-25/s-in-place
Dsvn-test-work/working_copies/special_tests-25/s-replace
Asvn-test-work/working_copies/special_tests-25/s-replace
U svn-test-work/working_copies/special_tests-25/s-reverse
but the buildbot appears to have missed the update to s-in-place. Is
this explainable in some way? Has serf simply dropped part of the
update? The buildbot is using serf 1.0.3 if that makes a difference.
The buildbot faillog was:
W: Couldn't find node 's-in-place' in actual output tree
W: * Node name: s-in-place
Path: svn-test-work/working_copies/special_tests-25/s-in-place
Contents: None
Properties: {}
Attributes: {'status': 'U '}
Children: None (node is probably a file)
W: Unequal at node special_tests-25
W: Unequal at node working_copies
W: Unequal at node svn-test-work
W: ACTUAL OUTPUT TREE:
svntest.wc.State(wc_dir, {
's-replace' : Item(status='A '),
's-reverse' : Item(status=' U'),
's-type': Item(status=' U'),
})
W: CWD: /home/bt/slaves/x64-centos/build/subversion/tests/cmdline
W: EXCEPTION: SVNTreeUnequal
Traceback (most recent call last):
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/main.py,
line 1415, in run
rc = self.pred.run(sandbox)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/testcase.py,
line 176, in run
return self.func(sandbox)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/special_tests.py,
line 1188, in incoming_symlink_changes
wc_dir, '-r', '2')
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/actions.py,
line 878, in run_and_verify_update
check_props)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/actions.py,
line 770, in verify_update
tree.compare_trees(output, actual_output, output_tree)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/tree.py,
line 692, in compare_trees
singleton_handler_b, b_baton)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/tree.py,
line 692, in compare_trees
singleton_handler_b, b_baton)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/tree.py,
line 692, in compare_trees
singleton_handler_b, b_baton)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/tree.py,
line 697, in compare_trees
singleton_handler_b(b_child, b_baton)
File
/home/bt/slaves/x64-centos/build/subversion/tests/cmdline/svntest/tree.py,
line 589, in default_singleton_handler
raise SVNTreeUnequal
SVNTreeUnequal
FAIL: special_tests.py 25: verify incoming symlink change behavior
--
Certified Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: No Apache httpd for Windows?
On 09.11.2012 16:10, Mark Phippard wrote: I know many of you are part of the httpd project, and I am not, so asking here. With the current Apache 2.2.x and 2.4.x there are no more Windows downloads available. Does anyone know why? I do not see anything on the mailing lists, but maybe I am just missing it. I expect wrowe just got tired of/ran out of time for building the Windows httpd binaries. That was a one-man-band volunteer effort, and since binaries aren't blessed release artefacts anyway, there's little chance of someone else stepping up. I can understand that maybe whoever was building the Win32 binaries stopped, or did not have time, but I am actually talking about the source code. There is no Win32 zip file as there always has been in the past. And there are no notes that say you should use the Unix tar to build. I was under the impression in the past, that the process of producing the Windows source zip file produced some extra content that was needed to do a build. That said, the docs do not specifically say anything about what source to download. Producing that Windows zip file, and the build scripts within, and generally maintaining the Windows build env was also a one-man effort. Did they stop posting the Windows zip file because it just is not needed, or is something going on? At this point I have to point out that, strictly speaking, this is kind of the wrong list to ask those questions. :) I am dealing with some weirdness that only happens on Windows, and did not happen with 2.2.22, so want to be sure it is not because I am building with the wrong source. The only difference between the Unix and Windows tarballs was the build scripts and the line endings. With the (finally) demise of MSVC 6, which required CRLF in .dsp and .dsw files, line endings are definitely no longer an issue. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: No Apache httpd for Windows?
On Fri, Nov 9, 2012 at 1:41 PM, Branko Čibej br...@wandisco.com wrote: Producing that Windows zip file, and the build scripts within, and generally maintaining the Windows build env was also a one-man effort. Did they stop posting the Windows zip file because it just is not needed, or is something going on? At this point I have to point out that, strictly speaking, this is kind of the wrong list to ask those questions. :) I know, but I just figured releasing the source archives in an open-source project is kind of an important thing. So I figured it must have been discussed somewhere and someone could point me to it. When the release was posted for signatures, it was implied they were coming soon: http://mail-archives.apache.org/mod_mbox/httpd-dev/201208.mbox/%3C5033E08F.6070301%40rowe-clan.net%3E The only difference between the Unix and Windows tarballs was the build scripts and the line endings. With the (finally) demise of MSVC 6, which required CRLF in .dsp and .dsw files, line endings are definitely no longer an issue. That is what I expected. I just figured the project would state this somewhere. The files are still listed as Unix tarballs which makes it sound like it is meant to build on Unix. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: No Apache httpd for Windows?
On 09.11.2012 19:50, Mark Phippard wrote: That is what I expected. I just figured the project would state this somewhere. The files are still listed as Unix tarballs which makes it sound like it is meant to build on Unix. It's kind of an informal policy here at the ASF that source release means all source needed to build on all supported platforms, except third-party dependencies. :) Which reminds me that we should consider stopping releasing a separate Windows zip file, with different contents and different line endings ourselves. If it's only an issue of unzip being more common on windows than tar+gunzip, then we can do the same as with tar.gz and tar.bz2 -- just package the same tree in a different archive format. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: [RFC] Non-normalizing Unicode Composition Awareness
On 9 nov 2012, at 14:28, C. Michael Pilato cmpil...@collab.net wrote: On 11/09/2012 07:49 AM, Branko Čibej wrote: On 09.11.2012 12:28, Thomas Åkesson wrote: I'm currently doing the grunt work of implementing the collation (done) and the LIKE and GLOB operators that we'll need (in progress). The next, and biggest, step will be to review the client and WC libraries to make sure that paths sent to the server always come from the wc.db, not from disk. I'm not closely following this problem or solution, but how does the above play out for svn import, svn mkdir IRI, svn delete IRI, etc? (If this is documented somewhere, a reference by way of response would suffice.) http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness The draft proposes that the server does not discriminate any composition, apart from ensuring that creation of new name collisions is not allowed. Ensuring that paths come from wc.db applies to existing object. We can discuss whether Mac client should normalize to NFC, but that would be an option in my opinion. /Thomas Å.
Re: serf buildbot FAIL on trunk@1407545
Philip Martin philip.mar...@wandisco.com writes: The centos buildbot failed on trunk@1407545. I can't reproduce it. The failing update produces: It's happened a second time on trunk@1407583. Between the failures it worked on trunk@1407556. -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: serf buildbot FAIL on trunk@1407545
On Fri, Nov 9, 2012 at 11:17 PM, Philip Martin philip.mar...@wandisco.com wrote: Philip Martin philip.mar...@wandisco.com writes: The centos buildbot failed on trunk@1407545. I can't reproduce it. The failing update produces: It's happened a second time on trunk@1407583. Between the failures it worked on trunk@1407556. The failing test (special_tests#25) added r1407131 (two days ago). Bert, do you have any ideas why this test failing some sometimes? -- Ivan Zhakov
Re: serf buildbot FAIL on trunk@1407545
On Fri, Nov 9, 2012 at 11:17 PM, Philip Martin philip.mar...@wandisco.com wrote: Philip Martin philip.mar...@wandisco.com writes: The centos buildbot failed on trunk@1407545. I can't reproduce it. The failing update produces: It's happened a second time on trunk@1407583. Between the failures it worked on trunk@1407556. Btw this test also failed on trunk@r1407274 before my change in ra_serf: http://ci.apache.org/builders/svn-x64-centos-gcc/builds/7581/steps/Test%20fsfs%2Bra_serf/logs/stdio -- Ivan Zhakov
Re: Content-Length in HEAD responses
On Fri, Nov 9, 2012 at 10:15 AM, C. Michael Pilato cmpil...@collab.netwrote: request, so I'm wondering ... does Apache just handle a HEAD as a GET under-the-hood and then discard the resulting response body? The comment Unless the handler does something special, yes, httpd will treat HEAD as a GET until it is time to send the response body...and simply drops the response body. -- justin
Re: Content-Length in HEAD responses
On 10.11.2012 04:59, Justin Erenkrantz wrote: On Fri, Nov 9, 2012 at 10:15 AM, C. Michael Pilato cmpil...@collab.netwrote: request, so I'm wondering ... does Apache just handle a HEAD as a GET under-the-hood and then discard the resulting response body? The comment Unless the handler does something special, yes, httpd will treat HEAD as a GET until it is time to send the response body...and simply drops the response body. That would imply that, if content-length doesn't get set on a HEAD response, but Transfer-Encoding: chunked does, then everything is correct, right? If somewhat inefficient. -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
