Re: Error - 411 Length Required (on Commit)
Guten Tag Dave Steckler, am Dienstag, 25. Juni 2013 um 00:35 schrieben Sie: How would one upgrade to svn 1.8.1 as it exists within TortoiseSVN? [...]For example, I have no idea what serf, amongst all the libraries used by svn, even is. Simply wait for the next release of TortoiseSVN or downgrade to an older version. Everything else is really much work if you're new to it. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Error - 411 Length Required (on Commit)
I think this is another instance of a proxy not supporting chunked Transfer-Encoding. For a commit to a 1.7 server the client sends a chunked POST, the proxy responds with a 411, and the client shows the error. For a commit to a 1.6 server the client sends a chunked PROPFIND, the proxy responds with a 411, the client fails to notice the 411 but still gives an error since the response doesn't contain the requested properties. This will probably be fixed in Subversion's libsvn_ra_serf rather than serf itself. Daniel Shahaf d...@daniel.shahaf.name writes: This quite resembles an issue reported last week which is intended to be fixed in serf 1.2.2. It's possible you could upgrade just your serf libraries, not svn as well (though, since you likely use a binary package, just upgrading to svn 1.8.1 packages that include serf 1.2.2 might be easiest). Sorry, don't have a thread link handy... Dave Steckler wrote on Sun, Jun 23, 2013 at 10:17:54 -0700: .I'm not on the list and couldn't find this in archive search...please cc me on any responses...thx! Was going to report this error over at the TortoiseSVN site, but apparently they are pointing over here. Here's the link to the discussion over on Tortoise: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061dsMessageId=3058859 Here's the text from over there (which includes repro, etc.). For me, same repro as below, and it's a simple matter of trying to commit anything and I get the 411 Length Required error as detailed below (i.e. me too). I'm running Win7 64 bit, latest patches, etc. = This is the right mailing list to report issues with TortoiseSVN. However, as the problem also occurs with the standard subversion command line client then the problem has to lie within the subversion library rather than any of the TortoiseSVN code. In case you are not aware, TortoiseSVN along with all other subversion clients is built on top of the standard subversion library which is provided by the subversion project itself. TSVN just provides the user-friendly front end. You can contact the subversion team on users at subversion.apache.org. Simon I’m running on Vista 32 bit and have been upgrading Tortoise for years successfully until now. REPRO · Update to 1.8.0 from 1.7 · Update local working copy · Modify a file and attempt to commit RESULT POST of '/svn/[project name]/!svn/me': 411 Length Required == -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
On Mon, Jun 24, 2013 at 03:40:44PM -0400, Nico Kadel-Garcia wrote: The normal way to handle changing deployment environments is with an actual configuration or deployment tool, such as autoconf, that sets the path to the locally detected python and uses *that*. The detected Python (if any) is available in Makefile as $(PYTHON). (I have nothing to say to the rest that wasn't already said somewhere on this thread (perhaps on the dev@ part of it).)
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
On Mon, Jun 24, 2013 at 09:47:17PM +0200, Ben Smith-Mannschott wrote: 0x18 is ^X, the ASCII control code for CANCEL. Seems to be working as designed. ;-) No more seriously though, it sure looks like a bug. 0x18 is a perfectly legal UTF-8 encoding of the unicode character U+0018. Every US-ASCII character is encoded as itself in UTF-8 and the first 128 Unicode code points are exactly US-ASCII. Works for me: % svnadmin create r % mv =( printf 'K 1\nx\nV 1\n\030\nEND\n' 0 ) r/db/revprops/0/0 mv: try to overwrite `r/db/revprops/0/0', overriding mode 0444 (r--r--r--)? y % svnadmin create r2 % ln -s =true r2/hooks/pre-revprop-change % svnsync init file://$PWD/r2 file://$PWD/r Copied properties for revision 0. % svnsync copy-revprops file://$PWD/r2 file://$PWD/r Copied properties for revision 0. % tail -5 r2/db/revprops/0/0 | xxd 000: 4b20 310a 780a 5620 310a 180a 454e 440a K 1.x.V 1...END. Did you pass --source-prop-encoding ? Daniel // Ben On Mon, Jun 24, 2013 at 7:30 PM, olli hauer oha...@gmx.de wrote: svnsync 1.8.0 fails if there is a non-printable characters in the commit message Error message: svnsync: E22: Safe data 'MFC r251249, r251251, r251252, r' was followed by non-ASCII byte 24: unable to convert to/from UTF-8 No issue with svnsync 1.7.10 (neon based) Parts of the file (synced with svnsync 1.7.10) $ cat $repo/db/revprops/251/251614 ... MFC r251249, r251251, r251252, r2512, r251254 and r251515: $ more $repo/db/revprops/251/251614 ... MFC r251249, r251251, r251252, r^X2512, r251254 and r251515: $ hexdump -C $repo/db/revprops/251/251614 ... 0070 31 2c 20 72 32 35 31 32 35 32 2c 20 72 18 32 35 |1, r251252, r.25| Culprit is the hex(18) sign. -- olli
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
Daniel Shahaf wrote on Tue, Jun 25, 2013 at 13:50:58 +: On Mon, Jun 24, 2013 at 09:47:17PM +0200, Ben Smith-Mannschott wrote: 0x18 is ^X, the ASCII control code for CANCEL. Seems to be working as designed. ;-) No more seriously though, it sure looks like a bug. 0x18 is a perfectly legal UTF-8 encoding of the unicode character U+0018. Every US-ASCII character is encoded as itself in UTF-8 and the first 128 Unicode code points are exactly US-ASCII. Works for me: % svnadmin create r % mv =( printf 'K 1\nx\nV 1\n\030\nEND\n' 0 ) r/db/revprops/0/0 mv: try to overwrite `r/db/revprops/0/0', overriding mode 0444 (r--r--r--)? y That last command should have been (equivalently, but without munging internals): % ln -s =true r/hooks/pre-revprop-change % svn ps -F =(printf '\030') --revprop -r0 x file://$PWD/r property 'x' set on repository revision 0 % svnadmin create r2 % ln -s =true r2/hooks/pre-revprop-change % svnsync init file://$PWD/r2 file://$PWD/r Copied properties for revision 0. % svnsync copy-revprops file://$PWD/r2 file://$PWD/r Copied properties for revision 0. % tail -5 r2/db/revprops/0/0 | xxd 000: 4b20 310a 780a 5620 310a 180a 454e 440a K 1.x.V 1...END. Did you pass --source-prop-encoding ? Daniel // Ben On Mon, Jun 24, 2013 at 7:30 PM, olli hauer oha...@gmx.de wrote: svnsync 1.8.0 fails if there is a non-printable characters in the commit message Error message: svnsync: E22: Safe data 'MFC r251249, r251251, r251252, r' was followed by non-ASCII byte 24: unable to convert to/from UTF-8 No issue with svnsync 1.7.10 (neon based) Parts of the file (synced with svnsync 1.7.10) $ cat $repo/db/revprops/251/251614 ... MFC r251249, r251251, r251252, r2512, r251254 and r251515: $ more $repo/db/revprops/251/251614 ... MFC r251249, r251251, r251252, r^X2512, r251254 and r251515: $ hexdump -C $repo/db/revprops/251/251614 ... 0070 31 2c 20 72 32 35 31 32 35 32 2c 20 72 18 32 35 |1, r251252, r.25| Culprit is the hex(18) sign. -- olli
WebDAV support in future versions of SVN server?
Is it still a long-term goal to maintain the ability to mount a SVN repository as a WebDAV folder? Based on this message from 2009: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462dsMessageId=1180976 It sounds like the SVN server is still planning on supporting WebDAV clients, but moving the svn client away from talking WebDAV to the HTTP server? But before I go and roll out WebDAV to our users, I'd like to make sure that SVN isn't going to drop WebDAV client support in the next few years.
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
Daniel Shahaf wrote on Tue, Jun 25, 2013 at 16:55:24 +0300: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 13:50:58 +: On Mon, Jun 24, 2013 at 09:47:17PM +0200, Ben Smith-Mannschott wrote: 0x18 is ^X, the ASCII control code for CANCEL. Seems to be working as designed. ;-) No more seriously though, it sure looks like a bug. 0x18 is a perfectly legal UTF-8 encoding of the unicode character U+0018. Every US-ASCII character is encoded as itself in UTF-8 and the first 128 Unicode code points are exactly US-ASCII. Works for me: % svnadmin create r % mv =( printf 'K 1\nx\nV 1\n\030\nEND\n' 0 ) r/db/revprops/0/0 mv: try to overwrite `r/db/revprops/0/0', overriding mode 0444 (r--r--r--)? y That last command should have been (equivalently, but without munging internals): % ln -s =true r/hooks/pre-revprop-change % svn ps -F =(printf '\030') --revprop -r0 x file://$PWD/r property 'x' set on repository revision 0 It still works when I use svn:log rather than x as the property name. Daniel % svnadmin create r2 % ln -s =true r2/hooks/pre-revprop-change % svnsync init file://$PWD/r2 file://$PWD/r Copied properties for revision 0. % svnsync copy-revprops file://$PWD/r2 file://$PWD/r Copied properties for revision 0. % tail -5 r2/db/revprops/0/0 | xxd 000: 4b20 310a 780a 5620 310a 180a 454e 440a K 1.x.V 1...END. Did you pass --source-prop-encoding ? Daniel // Ben On Mon, Jun 24, 2013 at 7:30 PM, olli hauer oha...@gmx.de wrote: svnsync 1.8.0 fails if there is a non-printable characters in the commit message Error message: svnsync: E22: Safe data 'MFC r251249, r251251, r251252, r' was followed by non-ASCII byte 24: unable to convert to/from UTF-8 No issue with svnsync 1.7.10 (neon based) Parts of the file (synced with svnsync 1.7.10) $ cat $repo/db/revprops/251/251614 ... MFC r251249, r251251, r251252, r2512, r251254 and r251515: $ more $repo/db/revprops/251/251614 ... MFC r251249, r251251, r251252, r^X2512, r251254 and r251515: $ hexdump -C $repo/db/revprops/251/251614 ... 0070 31 2c 20 72 32 35 31 32 35 32 2c 20 72 18 32 35 |1, r251252, r.25| Culprit is the hex(18) sign. -- olli
Re: WebDAV support in future versions of SVN server?
On Tue, Jun 25, 2013 at 09:55:15AM -0400, Thomas Harold wrote: Is it still a long-term goal to maintain the ability to mount a SVN repository as a WebDAV folder? Based on this message from 2009: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462dsMessageId=1180976 It sounds like the SVN server is still planning on supporting WebDAV clients, but moving the svn client away from talking WebDAV to the HTTP server? But before I go and roll out WebDAV to our users, I'd like to make sure that SVN isn't going to drop WebDAV client support in the next few years. WebDAV clients will be supported until at least Subversion 2.0 arrives because we won't break compatibility with any existing features until the Subversion 2.0 release. Any Subversion 1.x server must speak WebDAV due to this compatibility policy. So far, there are no plans whatsoever to jump to version 2.0. And even if we did, dropping support for old features is merely an option at that point. So WebDAV support might stay alive even in Subversion 2.0 and later.
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
On 2013-06-25 16:02, Daniel Shahaf wrote: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 16:55:24 +0300: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 13:50:58 +: On Mon, Jun 24, 2013 at 09:47:17PM +0200, Ben Smith-Mannschott wrote: 0x18 is ^X, the ASCII control code for CANCEL. Seems to be working as designed. ;-) No more seriously though, it sure looks like a bug. 0x18 is a perfectly legal UTF-8 encoding of the unicode character U+0018. Every US-ASCII character is encoded as itself in UTF-8 and the first 128 Unicode code points are exactly US-ASCII. Works for me: % svnadmin create r % mv =( printf 'K 1\nx\nV 1\n\030\nEND\n' 0 ) r/db/revprops/0/0 mv: try to overwrite `r/db/revprops/0/0', overriding mode 0444 (r--r--r--)? y That last command should have been (equivalently, but without munging internals): % ln -s =true r/hooks/pre-revprop-change % svn ps -F =(printf '\030') --revprop -r0 x file://$PWD/r property 'x' set on repository revision 0 It still works when I use svn:log rather than x as the property name. Daniel Thanks for your first diagnostic, I don't have all the details, the issue is part of an FreeBSD PR where this happened to a user. Since I have the same repository in sync (but with subversion 1.7.10) I've taken a look into the file which breaks the sync for the user with subversion 1.8. It is the following FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=179760 Additional I've ask the OP to join the users@ list so you can get more details from first hand. -- Thanks, olli
Re: Merge gives E160013 Error after upgrade to svn-1.7.10
Sorry to bump but hey I need help, and advice... Do I file a bug or what? something is definitely broken with merge, and as I said in my previous reply to myself, I can do this merge using TSVN on Windows, but it doesn't work from the command line and on the same server as where the repo is. I also tried on a fresh wc checkout, same problem. Help, what can I do get further with this? Full procedure and output here: http://pastebin.com/VcwmJ0wF /Joakim On 22/06/2013 13:13, Joakim Schramm wrote: Hi list, my first post as I subscribed due to my problem, so please be gentle in case I don't get it right ;-) After upgrading from svn-1.7.9 to 1.7.10 and doing a merge operation have done regularly during the last 2 years or so, I now get an E160013 Error: svn dev # svn merge ^/vendor/d7-core/drupal-7.x-dev_2013-Jun-06 ^/vendor/d7-core/current svn: E160013: File not found: revision 4124, path '/vendor/d7-core/drupal-7.x-dev_2013-Jun-06' The background is this: In my repo I run a vendor branch keeping track of Drupal as well as a collection of Drupal modules and themes. In the same repo I also vc a collection of web sites, which are all tracked against the vendor branches. On Thursday evening I upgraded to 1.7.10, and on Friday I made my first vendor update with the new version, updating Drupal 7 code, using the svn_load_dirs script: svn_load_dirs.pl -t drupal-7.x-dev_2013-June-21 -svn_username -svn_password svn://svn..com/www/vendor/d7-core current /tmp/drupal-7.x-dev and as from what I can judge nothing seems to be wrong with the output and the commits are done. I can post the output in case it's needed/wanted. I then (try to) make the merge operation above in the web root of one site resulting in the error. Subversion is running on a Gentoo Linux server using svnserve. I also work with this repo from a Windows workstation using TSVN and using the TSVN repo browser I can clearly see that the 'not found' file (which actually is a dir) is present. 'revision 4124' is the last revision in repo created by the load_dirs script. Well, I don't know where to start looking as I can't really see anything is wrong, except for the error message, but hopefully someone else can or have an idea, or is this possibly a bug? thanks, Joakim
Re: Merge gives E160013 Error after upgrade to svn-1.7.10
More information. I now tried to make a merge deeper in the wc, this time updating a module in drupal, same procedure with svn_load_dirs and guess what - that worked! http://pastebin.com/hVvpw4cv So from what I understand can't orient itself from the root of the wc, but well deeper into it. Or it might as well that it has to do with that the core files and modules have different paths in the repo /www/vendor/d7-core vs /www/vendor/d7-modules Joakim On 22/06/2013 13:13, Joakim Schramm wrote: Hi list, my first post as I subscribed due to my problem, so please be gentle in case I don't get it right ;-) After upgrading from svn-1.7.9 to 1.7.10 and doing a merge operation have done regularly during the last 2 years or so, I now get an E160013 Error: svn dev # svn merge ^/vendor/d7-core/drupal-7.x-dev_2013-Jun-06 ^/vendor/d7-core/current svn: E160013: File not found: revision 4124, path '/vendor/d7-core/drupal-7.x-dev_2013-Jun-06' The background is this: In my repo I run a vendor branch keeping track of Drupal as well as a collection of Drupal modules and themes. In the same repo I also vc a collection of web sites, which are all tracked against the vendor branches. On Thursday evening I upgraded to 1.7.10, and on Friday I made my first vendor update with the new version, updating Drupal 7 code, using the svn_load_dirs script: svn_load_dirs.pl -t drupal-7.x-dev_2013-June-21 -svn_username -svn_password svn://svn..com/www/vendor/d7-core current /tmp/drupal-7.x-dev and as from what I can judge nothing seems to be wrong with the output and the commits are done. I can post the output in case it's needed/wanted. I then (try to) make the merge operation above in the web root of one site resulting in the error. Subversion is running on a Gentoo Linux server using svnserve. I also work with this repo from a Windows workstation using TSVN and using the TSVN repo browser I can clearly see that the 'not found' file (which actually is a dir) is present. 'revision 4124' is the last revision in repo created by the load_dirs script. Well, I don't know where to start looking as I can't really see anything is wrong, except for the error message, but hopefully someone else can or have an idea, or is this possibly a bug? thanks, Joakim
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
olli hauer wrote on Tue, Jun 25, 2013 at 17:06:35 +0200: On 2013-06-25 16:02, Daniel Shahaf wrote: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 16:55:24 +0300: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 13:50:58 +: On Mon, Jun 24, 2013 at 09:47:17PM +0200, Ben Smith-Mannschott wrote: 0x18 is ^X, the ASCII control code for CANCEL. Seems to be working as designed. ;-) No more seriously though, it sure looks like a bug. 0x18 is a perfectly legal UTF-8 encoding of the unicode character U+0018. Every US-ASCII character is encoded as itself in UTF-8 and the first 128 Unicode code points are exactly US-ASCII. Works for me: % svnadmin create r % mv =( printf 'K 1\nx\nV 1\n\030\nEND\n' 0 ) r/db/revprops/0/0 mv: try to overwrite `r/db/revprops/0/0', overriding mode 0444 (r--r--r--)? y That last command should have been (equivalently, but without munging internals): % ln -s =true r/hooks/pre-revprop-change % svn ps -F =(printf '\030') --revprop -r0 x file://$PWD/r property 'x' set on repository revision 0 It still works when I use svn:log rather than x as the property name. Daniel Thanks for your first diagnostic, I don't have all the details, the issue is part of an FreeBSD PR where this happened to a user. Since I have the same repository in sync (but with subversion 1.7.10) I've taken a look into the file which breaks the sync for the user with subversion 1.8. It is the following FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=179760 So it indeed is FreeBSD - I thought the revnums looked familiar. I'll note the path of least resistance to getting svnsync to work is to ask someone with access to edit the log message on svn.freebsd.org. Daniel Additional I've ask the OP to join the users@ list so you can get more details from first hand.
Subversion Exception!
Subversion?? (Ctrl-C?? ??)?? ??D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_wc\wc_db.c?? 8443??(svn_dirent_is_absolute(local_abspath))
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
On 2013-06-26 01:05, Daniel Shahaf wrote: olli hauer wrote on Tue, Jun 25, 2013 at 17:06:35 +0200: On 2013-06-25 16:02, Daniel Shahaf wrote: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 16:55:24 +0300: Daniel Shahaf wrote on Tue, Jun 25, 2013 at 13:50:58 +: On Mon, Jun 24, 2013 at 09:47:17PM +0200, Ben Smith-Mannschott wrote: 0x18 is ^X, the ASCII control code for CANCEL. Seems to be working as designed. ;-) No more seriously though, it sure looks like a bug. 0x18 is a perfectly legal UTF-8 encoding of the unicode character U+0018. Every US-ASCII character is encoded as itself in UTF-8 and the first 128 Unicode code points are exactly US-ASCII. Works for me: % svnadmin create r % mv =( printf 'K 1\nx\nV 1\n\030\nEND\n' 0 ) r/db/revprops/0/0 mv: try to overwrite `r/db/revprops/0/0', overriding mode 0444 (r--r--r--)? y That last command should have been (equivalently, but without munging internals): % ln -s =true r/hooks/pre-revprop-change % svn ps -F =(printf '\030') --revprop -r0 x file://$PWD/r property 'x' set on repository revision 0 It still works when I use svn:log rather than x as the property name. Daniel Thanks for your first diagnostic, I don't have all the details, the issue is part of an FreeBSD PR where this happened to a user. Since I have the same repository in sync (but with subversion 1.7.10) I've taken a look into the file which breaks the sync for the user with subversion 1.8. It is the following FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=179760 So it indeed is FreeBSD - I thought the revnums looked familiar. I'll note the path of least resistance to getting svnsync to work is to ask someone with access to edit the log message on svn.freebsd.org. Daniel Additional I've ask the OP to join the users@ list so you can get more details from first hand. Hi Daniel, it turns out the OP was not using subversion from ports and the original apache subversion 1.7.x/1.8 has not this issue. Sorry for the noise and thanks for your help! -- Regards, olli
