Re: An error occurred during decompression
Kai Krueger writes: > I am currently unable to commit compressed (.gz) files to one of our > subversion servers. > > Every time I try and commit a compressed file, I get the following error: > > Transmitting file data .svn: E120104: Commit failed (details follow): > svn: E120104: Error running context: An error occurred during decompression > > If I rename the same file from e.g. blah.gz to blah.gnoz without > touching the content of the file, the commit succeeds. > > So it looks like something is triggering a compression/decompression > based on file name. > > This is an Ubuntu 14.04 server with svn being accessed through the http > protocol with apache dav svn. It is the standard ubuntu packaged > subversion (1.8.8) Which client is seeing the problem? Does disabling compression on the client fix the problem? Try something like: --config-option servers:global:http-compression=no I assume you have mod_deflate enabled on the server, can you show us the server configuration? Which version of httpd? Does disabling mod_deflate on the server fix the problem? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: assertion failed
On 06/30/2015 11:26 AM, Stefan Sperling wrote: On Mon, Jun 29, 2015 at 01:55:31PM +0200, Nikolas PATTAKOS wrote: Hi, I am running subversion version 1.8.13 (r1667537) on debian testing. I have a number of svn move commands on my computer pending to be submitted and I did an svn update to update my branch. This resulted in a number of conflicts which I tried to resolve but faced this message: Select: (mc) apply update to move destination, (p) postpone, (q) quit resolution, (h) help: mc svn: E235000: In file '/build/subversion-OpCIfE/subversion-1.8.13/subversion/libsvn_wc/wc_db_update_move.c' line 1039: assertion failed (move_dst_revision == expected_move_dst_revision || status == svn_wc__db_status_not_present) Aborted To me it looks like a subversion issue but I do not know what else to do. Could you provide a script that shows which sequence of move commands got you into this situation? Hi, My project's dir structure included : lib/ src/TestA src/TestB src/... and I changed it to lib/Tests/A lib/Tests/B src/.. I am pulling updates before submitting my changes and I asked svn to apply updates to move destination but then I get this error. I got one again today: svn update Updating '.': C src/TestCommunicationsDGPara U src/TestCommunicationsDGPara/src/TestCommunicationsDGPara.cpp U src/TestCommunicationsDGPara/src Updated to revision 1644. Tree conflict on 'src/TestCommunicationsDGPara' > local dir moved away, incoming dir edit upon update Select: (mc) apply update to move destination, (p) postpone, (q) quit resolution, (h) help: mc svn: E235000: In file '/build/subversion-OpCIfE/subversion-1.8.13/subversion/libsvn_wc/wc_db_update_move.c' line 1039: assertion failed (move_dst_revision == expected_move_dst_revision || status == svn_wc__db_status_not_present) Aborted Then I tried svn cleanup, moved lib/Tests/CommunicationsDGPara to its original location(by doing svn revert CommunicationsDGPAra) and svn update. This resulted in my files being lost, ie I could not see them under lib/Tests/ nor src/ . I do not know what is wrong but I think that under no circumstances or user mistake should a situation like this arise. Regards, Nikolas -- Nikolas Pattakos < nsp > Service d'Expérimentation et de Développement, Inria Bordeaux Sud-Ouest A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: assertion failed
Nikolas PATTAKOS writes: > My project's dir structure included : > > lib/ > src/TestA > src/TestB > src/... > > and I changed it to > > lib/Tests/A > lib/Tests/B > src/.. We need more precise instructions otherwise we just have to guess exactly what you did. Perhaps: svn co URL wc svn mkdir wc/lib/Tests svn mv wc/src/TestA wc/lib/Tests/A svn mv wc/src/TestB wc/lib/Tests/B svn up wc I cannot reproduce the problem when I try: svnadmin create repo --compatible-version 1.8 svnmucc -mm -U file://`pwd`/repo \ mkdir src \ mkdir lib \ mkdir src/tA \ mkdir src/tA/src \ put <(echo foo1) src/tA/src/foo svnmucc -mm -U file://`pwd`/repo put <(echo foo2) src/tA/src/foo svn co file://`pwd`/repo@1 wc svn mkdir wc/lib/tests svn mv wc/src/tA wc/lib/tests/A svn up wc --accept mc -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: An error occurred during decompression
Hello, thank you very much for your fast reply! With your help, I have managed to figure out what the issue was. I had a " AddEncoding x-gzip gz tgz" in my apache config. Once I removed that it now appears to work correctly again. The --config-option servers:global:http-compression=no option also worked. Enabling or disabling mod_deflate did on the other hand not appear to make any difference (or my enabling/disabling did not take effect). The apache version is 2.4.7 Thank you again, for helping me fix this! Kai On 7/3/15 2:13 AM, Philip Martin wrote: > Kai Krueger writes: > >> I am currently unable to commit compressed (.gz) files to one of our >> subversion servers. >> >> Every time I try and commit a compressed file, I get the following error: >> >> Transmitting file data .svn: E120104: Commit failed (details follow): >> svn: E120104: Error running context: An error occurred during decompression >> >> If I rename the same file from e.g. blah.gz to blah.gnoz without >> touching the content of the file, the commit succeeds. >> >> So it looks like something is triggering a compression/decompression >> based on file name. >> >> This is an Ubuntu 14.04 server with svn being accessed through the http >> protocol with apache dav svn. It is the standard ubuntu packaged >> subversion (1.8.8) > Which client is seeing the problem? Does disabling compression on the > client fix the problem? Try something like: > >--config-option servers:global:http-compression=no > > I assume you have mod_deflate enabled on the server, can you show us the > server configuration? Which version of httpd? Does disabling > mod_deflate on the server fix the problem? >
