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
TortoiseSVN-1.8.0.24401-win32-svn-1.8.0 bug
--- Subversion Exception! --- Subversion遇到了一个严重的问题。 麻烦您花点时间将这个问题报告给Subversion 请尽量详细的描述您之前尝试的操作。 不过希望您先在邮件存档中搜索一下同样的问题，避免重复提交。 您可以登录下面的地址搜索邮件存档： http://subversion.apache.org/mailing-lists.html Subversion产生的报告如下 (您可以用Ctrl-C快捷键复制 本对话框的内容到剪切板)： 文件 “D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c”，行 647：断言失败(peg_revnum != SVN_INVALID_REVNUM) --- 确定 ---
Re: Error - 411 Length Required (on Commit)
How would one upgrade to svn 1.8.1 as it exists within TortoiseSVN? That is, I simply run TortoiseSVN, check stuff in and out of my unfuddle repository, and am deliberately and blissfully unaware of all the machinations that happen when I right click in Explorer and choose "SVN Commit". For example, I have no idea what "serf", amongst all the libraries used by svn, even is. Thanks, Dave On Mon, Jun 24, 2013 at 2:41 AM, Daniel Shahaf wrote: > 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=4061&dsMessageId=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 > > > > > > > > == >
Re: svnsync 1.8.0 fails if there is a non-printable characters in the commit message
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. // Ben On Mon, Jun 24, 2013 at 7:30 PM, olli hauer 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: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
On Mon, Jun 24, 2013 at 12:00 PM, Daniel Shahaf wrote: > Branko Čibej wrote on Mon, Jun 24, 2013 at 16:32:56 +0200: >> On 24.06.2013 11:46, Daniel Shahaf wrote: >> > Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200: >> >> On 22.06.2013 17:46, Nico Kadel-Garcia wrote: >> >>> # Canonicalize path to python, correctly >> >>> for name in tools/server-side/svnpubsub/*.py; do >> >>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name >> >>> done >> >> The above will actually break the hook scripts. At best you can use >> >> "#!/usr/bin/python" in those scripts. >> > And _that_ will break them on FreeBSD. >> >> The discussion is about how to package svnpubsub into an RPM. I don't >> see what FreeBSD has to do with that. > > Changing #!/usr/local/bin/python to #!/usr/bin/python in a script in > trunk would break that script on FreeBSD. And using /usr/local/bin/python is broken for everyone else. It's easy enough to fix in the RPM .spec file, and I've done so. But since "/usr/bin/env python" is more portable, and in general works quite well, perhaps being consistent about using it among all the ".py" files in svnpubsub would be more safe. 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*.
svnsync 1.8.0 fails if there is a non-printable characters in the commit message
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: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Branko Čibej wrote on Mon, Jun 24, 2013 at 16:32:56 +0200: > On 24.06.2013 11:46, Daniel Shahaf wrote: > > Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200: > >> On 22.06.2013 17:46, Nico Kadel-Garcia wrote: > >>> # Canonicalize path to python, correctly > >>> for name in tools/server-side/svnpubsub/*.py; do > >>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name > >>> done > >> The above will actually break the hook scripts. At best you can use > >> "#!/usr/bin/python" in those scripts. > > And _that_ will break them on FreeBSD. > > The discussion is about how to package svnpubsub into an RPM. I don't > see what FreeBSD has to do with that. Changing #!/usr/local/bin/python to #!/usr/bin/python in a script in trunk would break that script on FreeBSD.
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
On 24.06.2013 11:46, Daniel Shahaf wrote: > Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200: >> On 22.06.2013 17:46, Nico Kadel-Garcia wrote: >>> # Canonicalize path to python, correctly >>> for name in tools/server-side/svnpubsub/*.py; do >>> sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name >>> done >> The above will actually break the hook scripts. At best you can use >> "#!/usr/bin/python" in those scripts. > And _that_ will break them on FreeBSD. The discussion is about how to package svnpubsub into an RPM. I don't see what FreeBSD has to do with that. -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: sunversion 1.8.0 crash on FreeBSD when WC path is symlink (regression) (not a FreeBSD specific!)
On Sun, Jun 23, 2013 at 02:46:29PM +0200, Stefan Sperling wrote: > On Sun, Jun 23, 2013 at 04:28:25PM +0400, Lev Serebryakov wrote: > > Hello, Lev. > > You wrote 21 июня 2013 г., 22:08:44: > > > > LS> Here is way to crash subversion 1.8.0 release on FreeBSD -- try to > > LS> update WC which is symlink to real WC. It worked in 1.7.x. Repository > > LS> and access scheme and repo's content doesn't matter, "serf" repo is > > LS> used for illustration, but it crashes with any repo and any scheme > > LS> (https, svn, etc). > > Problem is not FreeBSD-specific, here is output on CentOS 6 x86_64 > > I can reproduce this on OpenBSD, too. > > Can you please file an issue? Fix committed: http://svn.apache.org/r1496007 I'll nominate this fix for backport to 1.8.1. Thanks for your report!
Re: E175004: The PROPFIND response did not include the requested properties
That is the problem here as well. We are using hosted svn from atlassian, so this may be affecting a lot of users. Here is the output with our server name changed: $ curl -i -X PROPFIND https://ourserver.atlassian.net/svn/OurRepo HTTP/1.1 401 Authorization Required Server: nginx Date: Mon, 24 Jun 2013 12:27:37 GMT Content-Type: text/html; charset=iso-8859-1 Connection: keep-alive WWW-Authenticate: Basic realm="Subversion Repository" Content-Length: 491 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. Apache/2.2.3 (CentOS) Server at ourserver.atlassian.net Port 80 From: Philip Martin Sent: Monday, June 24, 2013 7:28 AM To: Josh Geller Cc: users@subversion.apache.org Philip Martin writes: > Is there an nginx proxy in front of Apache? I suspect this is another > case of the proxy not supporting chunked Transfer-Encoding, coupled with > the bug in 1.8.0 that causes the client to treat a 411 error as success. > When this happens svn_ra_serf__fetch_node_props will go on to produce > the error you see. I've installed nginx as a reverse proxy and I can confirm that it does give exactly that error on commit. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: E175004: The PROPFIND response did not include the requested properties
Philip Martin writes: > Is there an nginx proxy in front of Apache? I suspect this is another > case of the proxy not supporting chunked Transfer-Encoding, coupled with > the bug in 1.8.0 that causes the client to treat a 411 error as success. > When this happens svn_ra_serf__fetch_node_props will go on to produce > the error you see. I've installed nginx as a reverse proxy and I can confirm that it does give exactly that error on commit. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: 1.8.0 bug - The PROPFIND response did not include the requested properties
CyberMew writes: > Error: The PROPFIND response did not include the requested properties > > Just updated from latest 1.7.x to 1.8.0 on Windows 7 64bit machine. Receive > the above error message through tortisesvn. Using svn command line doesn't > make a difference. > > Happens to all my repos. I suspect another instance of a reverse proxy like nginx not supporting chunked Transfer-Encoding. See http://svn.haxx.se/users/archive-2013-06/0255.shtml -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: E175004: The PROPFIND response did not include the requested properties
Philip Martin writes: > If you run something like: > >curl -H - http://server/repository > > the Server line might identify the proxy. Oops! Wrong option. curl -I http://server/repository or perhaps curl -i -X PROPFIND http://server/repository or perhaps visit http://server/repository/non/existant in a web browser. I'm not sure if there is a reliable way to identify a proxy. -- Philip
Re: E175004: The PROPFIND response did not include the requested properties
Josh Geller writes: > Get this message when attempting to commit either through svn command > line (1.8.0) or TortoiseSVN 1.8.0. This is a working set that was > upgraded from svn 1.7, and the server is a hosted svn on atlassian.net > which is Subversion version 1.6.11 (r934486). Others are having the > same problem here: > https://groups.google.com/forum/#!topic/tortoisesvn/o5taYV-bm0c Is there an nginx proxy in front of Apache? I suspect this is another case of the proxy not supporting chunked Transfer-Encoding, coupled with the bug in 1.8.0 that causes the client to treat a 411 error as success. When this happens svn_ra_serf__fetch_node_props will go on to produce the error you see. If you run something like: curl -H - http://server/repository the Server line might identify the proxy. You might be able to see the failed PROPFIND if you have access to the proxy logs. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: svnpubsub dependcy problem building RPM's for Subverssion 1.8.0
Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200: > On 22.06.2013 17:46, Nico Kadel-Garcia wrote: > > # Canonicalize path to python, correctly > > for name in tools/server-side/svnpubsub/*.py; do > > sed -i 's|#!/usr/local/bin/python|#!/usr/bin/env python|g' $name > > done > > The above will actually break the hook scripts. At best you can use > "#!/usr/bin/python" in those scripts. And _that_ will break them on FreeBSD.
Re: Error - 411 Length Required (on Commit)
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=4061&dsMessageId=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 > > > > > ==
RE: ra_serf PROPFIND refused by Nginx
> -Original Message- > From: Bartosz Fabianowski [mailto:free...@chillt.de] > Sent: 23 June 2013 20:21 > To: users@subversion.apache.org > Subject: ra_serf PROPFIND refused by Nginx > > Hi list, > > I recently switched from svn 1.7 to 1.8 and with it, from > neon to serf. > I am now getting the following error for many repositories: > > % svn co http://svn.mkgmap.org.uk/mkgmap/trunk > svn: E175004: The PROPFIND response did not include the > requested properties > > Wireshark tells me that this is because the PROPFIND request > was refused > by the server with HTTP error 411, length required. Even though the > server claims to support HTTP 1.1, chunked transfer encoding does not > appear to work. The server identifies itself as Nginx, which > leads me to > believe that I am dealing with a reverse proxy. > > I worked around the issue by modifying > subversion/libsvn_ra_serf/util.c > to force HTTP 1.0: > > - /* HTTP/1.1? (or later) */ > - if (sl.version != SERF_HTTP_10) > -handler->session->http10 = FALSE; > > Clearly, always forcing HTTP 1.0 is not the right solution. But maybe > svn should automatically switch to HTTP 1.0 when it receives a 411 > response to a chunked request, telling it that the server (or a proxy) > does not support chunked transfers? > > - Bartosz FYI there was some discussion about this issue with nginx last week, this thread (amonsgt others) for example: http://svn.haxx.se/users/archive-2013-06/0180.shtml ~ mark c
