Re: Error "mod_dav_svn close_stream: error closing write stream" using a write-through proxy
Guten Tag Thorsten Schöning, am Samstag, 15. August 2015 um 16:16 schrieben Sie: >> [Sat Aug 15 11:35:13.591510 2015] [dav:error] [client a.b.c.d:36370] >> mod_dav_svn close_stream: error closing write stream [500, #185004] >> [Sat Aug 15 11:35:13.591525 2015] [dav:error] [client a.b.c.d:36370] >> Unexpected end of svndiff input [500, #185004] Using tcpdump and wireshark I was able to capture unencrypted traffic from the local part of my SSH tunnel to my private httpd and back. Request is coming from port 1 to httpd port 80 and the response gets send back from port 80 to port 1 and is then forwarded through the tunnel to the public httpd and from there to my client which is showing the error. So the communication in general should work and it doesn't look like a connection is closed to early or such, else the error wouldn't be received by my client and I wouldn't get unencrypted data heading port 80 of my local httpd... In the request I can even see my changed data with the correct svndiff0 header and such, just like from a local successing commit. Some headers differ, but I guess that's because mod_proxy and I couldn't get it to force chunked encoding and such, it just seemed to ignore it. I simply don't understand why svn is failing to read the svndiff window properly... > 44 17:16:15.058222 192.168.100.20 192.168.100.2 HTTP914 PUT > /src/Testprodukt/!svn/wrk/d73a9537-4083-0e40-aab3-e4bd2f9156e6/trunk/testmurks.txt > HTTP/1.1 (application/vnd.svn-svndiff) > 00 00 03 04 00 06 00 00 00 00 00 00 00 00 08 00 > 0010 45 00 03 82 6a e6 40 00 40 06 83 28 c0 a8 64 14 E...j.@.@..(..d. > 0020 c0 a8 64 02 9d d8 00 50 88 09 22 45 4a ab 6e af ..dP.."EJ.n. > 0030 80 18 01 56 4c dc 00 00 01 01 08 0a 02 aa 48 a1 ...VL.H. > 0040 02 aa 48 a0 50 55 54 20 2f 73 72 63 2f 54 65 73 ..H.PUT /src/Tes > 0050 74 70 72 6f 64 75 6b 74 2f 21 73 76 6e 2f 77 72 tprodukt/!svn/wr > 0060 6b 2f 64 37 33 61 39 35 33 37 2d 34 30 38 33 2d k/d73a9537-4083- > 0070 30 65 34 30 2d 61 61 62 33 2d 65 34 62 64 32 66 0e40-aab3-e4bd2f > 0080 39 31 35 36 65 36 2f 74 72 75 6e 6b 2f 74 65 73 9156e6/trunk/tes > 0090 74 6d 75 72 6b 73 2e 74 78 74 20 48 54 54 50 2f tmurks.txt HTTP/ > 00a0 31 2e 31 0d 0a 48 6f 73 74 3a 20 73 75 62 76 65 1.1..Host: subve > 00b0 72 73 69 6f 6e 2e 70 6f 74 73 64 61 6d 2e 61 6d rsion.potsdam.am > 00c0 2d 73 6f 66 74 2e 64 65 3a 33 36 39 32 0d 0a 41 -soft.de:3692..A > 00d0 75 74 68 6f 72 69 7a 61 74 69 6f 6e 3a 20 42 61 uthorization: Ba [...] > 0110 65 72 2d 41 67 65 6e 74 3a 20 53 56 4e 2f 31 2e er-Agent: SVN/1. > 0120 39 2e 30 20 28 78 36 34 2d 6d 69 63 72 6f 73 6f 9.0 (x64-microso > 0130 66 74 2d 77 69 6e 64 6f 77 73 29 20 73 65 72 66 ft-windows) serf > 0140 2f 31 2e 33 2e 38 20 54 6f 72 74 6f 69 73 65 53 /1.3.8 TortoiseS > 0150 56 4e 2d 31 2e 39 2e 30 2e 32 36 36 35 32 0d 0a VN-1.9.0.26652.. > 0160 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 Content-Type: ap > 0170 70 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 73 76 plication/vnd.sv > 0180 6e 2d 73 76 6e 64 69 66 66 0d 0a 41 63 63 65 70 n-svndiff..Accep > 0190 74 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70 t-Encoding: gzip > 01a0 0d 0a 44 41 56 3a 20 68 74 74 70 3a 2f 2f 73 75 ..DAV: http://su > 01b0 62 76 65 72 73 69 6f 6e 2e 74 69 67 72 69 73 2e bversion.tigris. > 01c0 6f 72 67 2f 78 6d 6c 6e 73 2f 64 61 76 2f 73 76 org/xmlns/dav/sv > 01d0 6e 2f 64 65 70 74 68 2c 20 68 74 74 70 3a 2f 2f n/depth, http:// > 01e0 73 75 62 76 65 72 73 69 6f 6e 2e 74 69 67 72 69 subversion.tigri > 01f0 73 2e 6f 72 67 2f 78 6d 6c 6e 73 2f 64 61 76 2f s.org/xmlns/dav/ > 0200 73 76 6e 2f 6d 65 72 67 65 69 6e 66 6f 2c 20 68 svn/mergeinfo, h > 0210 74 74 70 3a 2f 2f 73 75 62 76 65 72 73 69 6f 6e ttp://subversion > 0220 2e 74 69 67 72 69 73 2e 6f 72 67 2f 78 6d 6c 6e .tigris.org/xmln > 0230 73 2f 64 61 76 2f 73 76 6e 2f 6c 6f 67 2d 72 65 s/dav/svn/log-re > 0240 76 70 72 6f 70 73 0d 0a 58 2d 53 56 4e 2d 56 65 vprops..X-SVN-Ve > 0250 72 73 69 6f 6e 2d 4e 61 6d 65 3a 20 32 37 39 0d rsion-Name: 279. > 0260 0a 58 2d 53 56 4e 2d 42 61 73 65 2d 46 75 6c 6c .X-SVN-Base-Full > 0270 74 65 78 74 2d 4d 44 35 3a 20 37 63 33 36 66 34 text-MD5: 7c36f4 > 0280 33 34 64 62 65 66 39 37 32 64 36 33 62 62 38 61 34dbef972d63bb8a > 0290 64 33 38 38 64 33 35 39 61 63 0d 0a 58 2d 53 56 d388d359ac..X-SV > 02a0 4e 2d 52 65 73 75 6c 74 2d 46 75 6c 6c 74 65 78 N-Result-Fulltex > 02b0 74 2d 4d 44 35 3a 20 39 34 64 66 36 33 38 36 38 t-MD5: 94df63868 > 02c0 32 38 65 36 33 61 66 31 39 64 32 37 63 32 31 36 28e63af19d27c216 > 02d0 33 37 61 37 37 66 62 0d 0a 58 2d 46 6f 72 77 61 37a77fb..X-Forwa > 02e0 72 64 65 64 2d 46 6f 72 3a 20 31 37 38 2e 30 2e rded-For: 178.0. > 02f0 39 37 2e 32 30 36 0d 0a 58 2d 46 6f 72 77 61 72 97.206..X-Forwar > 0300 64 65 64 2d 48 6f 73 74 3a 20 73 6f 66 74 77 61 ded-Host: softwa > 0310 72 65 2e 65 6c 72 65
Re: Error "mod_dav_svn close_stream: error closing write stream" using a write-through proxy
Guten Tag Thorsten Schöning, am Montag, 17. August 2015 um 19:59 schrieben Sie: >> 44 17:16:15.058222 192.168.100.20 192.168.100.2 HTTP914 PUT >> /src/Testprodukt/!svn/wrk/d73a9537-4083-0e40-aab3-e4bd2f9156e6/trunk/testmurks.txt >> HTTP/1.1 (application/vnd.svn-svndiff) A readable version: > PUT > /src/Testprodukt/!svn/wrk/d73a9537-4083-0e40-aab3-e4bd2f9156e6/trunk/testmurks.txt > HTTP/1.1 > Host: subversion.potsdam.am-soft.de:3692 > Authorization: Basic > User-Agent: SVN/1.9.0 (x64-microsoft-windows) serf/1.3.8 > TortoiseSVN-1.9.0.26652 > Content-Type: application/vnd.svn-svndiff > Accept-Encoding: gzip > DAV: http://subversion.tigris.org/xmlns/dav/svn/depth, > http://subversion.tigris.org/xmlns/dav/svn/mergeinfo, > http://subversion.tigris.org/xmlns/dav/svn/log-revprops > X-SVN-Version-Name: 279 > X-SVN-Base-Fulltext-MD5: 7c36f434dbef972d63bb8ad388d359ac > X-SVN-Result-Fulltext-MD5: 94df6386828e63af19d27c21637a77fb > X-Forwarded-For: 178.0.97.206 > X-Forwarded-Host: software.elrev.net > X-Forwarded-Server: software.elrev.net > Connection: close > Content-Length: 35 > > SVNk}\Z > murksdreck 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
JavaHL and Transactions
I am in the process of developing a set of utilities for managing the 'promotion' of code from trunk to specific tags etc. The project has been doing tag based development for more than 10 years and is now moving from CVS to SVN. I am using the JavaHL api from org.apache.subversion.javahl >From my experience as a user of Subversion in Eclipse and other tools I come to expect support for performing multiple operations in a 'transaction' which results in one new version with the relevant comments. I cannot figure out how to do this with the JavaHL api. As an example: Give the following structure: PROJECT1/trunk/sub-project1/files/test.txt PROJECT1/trunk/sub-project1/files/test2.txt PROJECT1/trunk/sub-project1/morefiles/test3.txt A promotion of sub-project1 to 'integration' would entail copy from PROJECT1/trunk/sub-project1 to PROJECT1/tags/integration/sub- project1 This can be done on cmd line using svn copy Assume someone then modifies test2.txt and test3/txt on trunk and committed those changes. Our requirements are to make a backup of the target sub project before applying the changes so that a 'demote' can be performed if needed. A new promotion should now entail: create: PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/morefiles move the files that are being modified: PROJECT1/tags/integration/sub-project1/files/test2.txt to PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files/test2.txt PROJECT1/tags/integration/sub-project1/morefiles/test3.txt to PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/morefiles/test3.txt copy the file that is not modified: PROJECT1/tags/integration/sub-project1/files/test.txt to PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files/test.txt copy the modified files from trunk to tags/integration PROJECT1/trunk/sub-project1/files/test2.txt to PROJECT1/tags/integration/sub-project1/files/test2.txt PROJECT1/trunk/sub-project1/morefiles/test3.txt to PROJECT1/trunk/sub-project1/morefiles/test3.txt To perform these operations involve multiple api calls and a new version for each operation. The api allows for multiple files are in the same source and target folder in the case of copy and move operations. It would be some much cleaner with transactions resulting in one new version so that it is easy to identify all the related operations. >From an exploration of the C api it seems that transactions are supported. I would like to know if I have missed something somewhere. Regards Corneil du Plessis
Re: JavaHL and Transactions
On 18.08.2015 08:34, corneil.duples...@gmail.com wrote: > I am in the process of developing a set of utilities for managing the > 'promotion' of code from trunk to specific tags etc. The project has been > doing tag based development for more than 10 years and is now moving from > CVS to SVN. > > I am using the JavaHL api from org.apache.subversion.javahl > From my experience as a user of Subversion in Eclipse and other tools I > come to expect support for performing multiple operations in a > 'transaction' which results in one new version with the relevant comments. > > I cannot figure out how to do this with the JavaHL api. > > As an example: > Give the following structure: > PROJECT1/trunk/sub-project1/files/test.txt > PROJECT1/trunk/sub-project1/files/test2.txt > PROJECT1/trunk/sub-project1/morefiles/test3.txt > > A promotion of sub-project1 to 'integration' would entail > copy from PROJECT1/trunk/sub-project1 to PROJECT1/tags/integration/sub- > project1 > This can be done on cmd line using svn copy > > > Assume someone then modifies test2.txt and test3/txt on trunk and committed > those changes. Our requirements are to make a backup of the target sub > project before applying the changes so that a 'demote' can be performed if > needed. > A new promotion should now entail: > create: > PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files > PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/morefiles > move the files that are being modified: > PROJECT1/tags/integration/sub-project1/files/test2.txt to > PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files/test2.txt > PROJECT1/tags/integration/sub-project1/morefiles/test3.txt to > PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/morefiles/test3.txt > copy the file that is not modified: > PROJECT1/tags/integration/sub-project1/files/test.txt to > PROJECT1/tags/BACKUP_integration_20150812_180902_username/sub-project1/files/test.txt > copy the modified files from trunk to tags/integration > PROJECT1/trunk/sub-project1/files/test2.txt to > PROJECT1/tags/integration/sub-project1/files/test2.txt > PROJECT1/trunk/sub-project1/morefiles/test3.txt to > PROJECT1/trunk/sub-project1/morefiles/test3.txt > > > To perform these operations involve multiple api calls and a new version > for each operation. > The api allows for multiple files are in the same source and target folder > in the case of copy and move operations. > > It would be some much cleaner with transactions resulting in one new > version so that it is easy to identify all the related operations. > > From an exploration of the C api it seems that transactions are supported. > I would like to know if I have missed something somewhere. There is no public API equivalent for the functionality of the svnmucc tool. There's a *private* API for that in libsvn_client, but it's not exposed in JavaHL. In C, you can get equivalent functionality by using the libsvn_ra layer directly; most of that is available in JavaHL through the ISVNRemote interface in 1.9. See ISVNRemote.getCommitEditor() and ISVNEditor. -- Brane
