Sample repo dump
Hi all, I am working on a tool that will extract data from svn dumps (such as produced by `svnadmin dump` and `svnrdump`). I would like to make sure I can handle all kinds of cases, both common and corner cases (not error cases such as malformed dumps). Is there a sample repo or sample dump file that I can use? I would like it to include as many types of flows as possible (add/copy/delete/move for both files and directories, merges of various kinds, branches, etc.) while also keeping the total amount of revisions and files low to aid in debugging. Probably just one or two revisions with each type of flow (or combinations of flows if they need special handling when coming together in a single revision). Anyone have such a thing? Thanks P.S. I will check the list for replies, but would appreciate it if I can be explicitly Cc:ed with replies, too. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
Re: An error occurred during decompression
"Chao.Guan" writes: > I am using TortoiseSVN 1.8.7, Build 25475 - 64 Bit on my Win7. I happened to > see this information while updating contents: "ra_serf: An error occurred > during decompression". > > I have searched the source code of TortoiseSVN 1.8.7 but didn't find any > related code about it. > > I can't locate which commit cause the problem because there are about 100 > commit and each commit has 40-50M and plenty of files. > Can you guys give me some hints? What caused this error? What can I do to > fix it? > > By the way, one of my colleagues is using TortoiseSVN 1.7.11 on Win7, he has > this problem: "REPIRT of '/svn/st/!svn/vcc/default': Could not read chunk > size: Secure connection truncated". Maybe those two error reports has the > same root cause. Also, I can't find the related source code. > > Guys, help me with that, please! http://svn.haxx.se/dev/archive-2014-10/0004.shtml There is a serf bug that causes an error on checkout/update bigger than 4GB: svn: E120104: ra_serf: An error occurred during decompression This was fixed in serf 1.3.8. You may be able to work around this bug by disabling skelta mode on the client: http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default You can also work around the bug by disabling HTTP compression on the client or the server. However if the server is Apache 2.2 and you disable HTTP compression on the client while it remains enabled on the server you may trigger an Apache bug: 1.8 client: svn: E120106: ra_serf: The server sent a truncated HTTP response body. 1.7 client: svn: E175002: REPORT of '...': Could not read chunk size: connection was closed by server The Apache bug is a server crash so one user may see the error when some other user triggers the bug. The Apache bug is fixed in 2.4. You can work around the Apache bug by disabling HTTP compression on the server. Note HTTP compression is distinct from the deltas that Subversion uses between client and server. Disabling HTTP compression does not stop Subversion clients sending/receiving deltas. Disabling HTTP compression will mostly affect non-Subversion clients such as web browsers. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Why does svn patch fail for externals on add/delete?
Please Cc responses as I am not subscribed to the list. I'm primarily a Tortoise user under Windows, but have recently needed to start using the command line client more frequently. Our development environment heavily leverages externals and developers often distribute patches as a means for code review. With the command line client I've discovered that "svn patch" fails with an E155005: No write-lock error when applying a patch which adds or deletes files which span externals. I've observed this with both 1.7.7 and 1.8.10. I've had no problems when applying such patches with the Tortoise patch mechanism. A trivial example for clarity: Assume the following wc structure: test1/ fileA.txt externals/ test2/ fileB.txt [gmyers@pc test1]$ svn -v status 22 gmyers . 22 gmyers externals Xexternals/test2 21 gmyers fileA.txt Performing status on external item at 'externals/test2': 11 gmyers /home/gmyers/svnadmin_test/demo/test1/externals/test2 11 gmyers /home/gmyers/svnadmin_test/demo/test1/externals/test2/fileB.txt Now assume I have three patch files which perform the following operations: 1) Add a file file2.dat to externals/test2/, 2)Delete externals/test2/fileB.txt, 3) Modify externals/test2/fileB.txt. The patches were all generated by performing the desired task and dumping the result from svn diff. [gmyers@pc test1]$ cat add.patch Index: externals/test2/file2.dat === --- externals/test2/file2.dat (revision 0) +++ externals/test2/file2.dat (working copy) @@ -0,0 +1 @@ +This is file2. [gmyers@pc test1]$ cat delete.patch Index: externals/test2/fileB.txt === --- externals/test2/fileB.txt (revision 1) +++ externals/test2/fileB.txt (working copy) @@ -1 +0,0 @@ -This is fileB.txt [gmyers@pc test1]$ cat modify.patch Index: externals/test2/fileB.txt === --- externals/test2/fileB.txt (revision 1) +++ externals/test2/fileB.txt (working copy) @@ -1 +1,3 @@ This is fileB.txt + +Add some text. Now I'll attempt to apply the patches. The "add" patch returns E155005 and although it creates the new file2.dat file it fails to add it to svn: [gmyers@pc test1]$ svn patch add.patch svn: E155005: No write-lock in '/home/gmyers/svnadmin_test/demo/test1/externals/test2' The "delete" patch returns E155005 and does nothing: [gmyers@pc test1]$ svn patch delete.patch svn: E155005: No write-lock in '/home/gmyers/svnadmin_test/demo/test1/externals/test2' The "modify" patch succeeds as expected: [gmyers@pc test1]$ svn patch modify.patch U externals/test2/fileB.txt I'm wondering if this is a bug or the intended behavior? If it is intended then what is the reasoning behind the apparent need for a lock only for adds/deletes to externals but not for modify operations? Is there any sort of recommended workaround for this issue? Thanks, Griffin Myers
Re: Why does svn patch fail for externals on add/delete?
This error is about the working copy lock, not user locks. This lock makes sure only a single operation can change (a part of) the working copy at the same time, to avoid breaking your working copy. The problem here is that patch locks only one working copy, but your patch tries to change multiple working copies. (Directory externals are separate working copies). This is a scenario that was never designed for patch. Bert From: Griffin Myers Sent: Tuesday, November 4, 2014 2:56 PM To: users@subversion.apache.org Please Cc responses as I am not subscribed to the list. I’m primarily a Tortoise user under Windows, but have recently needed to start using the command line client more frequently. Our development environment heavily leverages externals and developers often distribute patches as a means for code review. With the command line client I’ve discovered that “svn patch” fails with an E155005: No write-lock error when applying a patch which adds or deletes files which span externals. I’ve observed this with both 1.7.7 and 1.8.10. I’ve had no problems when applying such patches with the Tortoise patch mechanism. A trivial example for clarity: Assume the following wc structure: test1/ fileA.txt externals/ test2/ fileB.txt [gmyers@pc test1]$ svn -v status 22 gmyers . 22 gmyers externals Xexternals/test2 21 gmyers fileA.txt Performing status on external item at 'externals/test2': 11 gmyers /home/gmyers/svnadmin_test/demo/test1/externals/test2 11 gmyers /home/gmyers/svnadmin_test/demo/test1/externals/test2/fileB.txt Now assume I have three patch files which perform the following operations: 1) Add a file file2.dat to externals/test2/, 2)Delete externals/test2/fileB.txt, 3) Modify externals/test2/fileB.txt. The patches were all generated by performing the desired task and dumping the result from svn diff. [gmyers@pc test1]$ cat add.patch Index: externals/test2/file2.dat === --- externals/test2/file2.dat (revision 0) +++ externals/test2/file2.dat (working copy) @@ -0,0 +1 @@ +This is file2. [gmyers@pc test1]$ cat delete.patch Index: externals/test2/fileB.txt === --- externals/test2/fileB.txt (revision 1) +++ externals/test2/fileB.txt (working copy) @@ -1 +0,0 @@ -This is fileB.txt [gmyers@pc test1]$ cat modify.patch Index: externals/test2/fileB.txt === --- externals/test2/fileB.txt (revision 1) +++ externals/test2/fileB.txt (working copy) @@ -1 +1,3 @@ This is fileB.txt + +Add some text. Now I’ll attempt to apply the patches. The “add” patch returns E155005 and although it creates the new file2.dat file it fails to add it to svn: [gmyers@pc test1]$ svn patch add.patch svn: E155005: No write-lock in '/home/gmyers/svnadmin_test/demo/test1/externals/test2' The “delete” patch returns E155005 and does nothing: [gmyers@pc test1]$ svn patch delete.patch svn: E155005: No write-lock in '/home/gmyers/svnadmin_test/demo/test1/externals/test2' The “modify” patch succeeds as expected: [gmyers@pc test1]$ svn patch modify.patch U externals/test2/fileB.txt I’m wondering if this is a bug or the intended behavior? If it is intended then what is the reasoning behind the apparent need for a lock only for adds/deletes to externals but not for modify operations? Is there any sort of recommended workaround for this issue? Thanks, Griffin Myers
Re: Why does svn patch fail for externals on add/delete?
On Tue, Nov 04, 2014 at 02:47:59PM +, Bert Huijben wrote: > The problem here is that patch locks only one working copy, but your patch > tries to change multiple working copies. (Directory externals are separate > working copies). This is a scenario that was never designed for patch. I see no reason it couldn't be made to work, though. svn patch could grab the lock on the external as well, couldn't it? I don't see why not. If so, I (original author of svn patch) think this warrants an issue in our bug tracker.
RE: Why does svn patch fail for externals on add/delete?
That would be great if this could be tracked as a bug and eventually fixed. For me it was very confusing that a modify operation would succeed but an add/delete would not, but this could just be a lack of low level svn understanding on my part particularly as it pertains to locks. Thanks! -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, November 04, 2014 10:01 AM To: Bert Huijben Cc: Griffin Myers; users@subversion.apache.org Subject: Re: Why does svn patch fail for externals on add/delete? On Tue, Nov 04, 2014 at 02:47:59PM +, Bert Huijben wrote: > The problem here is that patch locks only one working copy, but your patch > tries to change multiple working copies. (Directory externals are separate > working copies). This is a scenario that was never designed for patch. I see no reason it couldn't be made to work, though. svn patch could grab the lock on the external as well, couldn't it? I don't see why not. If so, I (original author of svn patch) think this warrants an issue in our bug tracker.
Re: Why does svn patch fail for externals on add/delete?
On Tue, Nov 04, 2014 at 04:21:37PM +, Griffin Myers wrote: > That would be great if this could be tracked as a bug and eventually fixed. Do you have time to file an issue? If so, please do so, pointing to this mailing list thread in the archives (e.g. at svn.haxx.se). Please see http://subversion.apache.org/reporting-issues.html for more information. Thanks!
RE: Why does svn patch fail for externals on add/delete?
Issue filed at: http://subversion.tigris.org/issues/show_bug.cgi?id=4525 Thanks for your help. -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, November 04, 2014 11:35 AM To: Griffin Myers Cc: Bert Huijben; users@subversion.apache.org Subject: Re: Why does svn patch fail for externals on add/delete? On Tue, Nov 04, 2014 at 04:21:37PM +, Griffin Myers wrote: > That would be great if this could be tracked as a bug and eventually fixed. Do you have time to file an issue? If so, please do so, pointing to this mailing list thread in the archives (e.g. at svn.haxx.se). Please see http://subversion.apache.org/reporting-issues.html for more information. Thanks!
RE: An error occurred during decompression
> From: users-return-22456-mr_kernel=163@subversion.apache.org > [mailto:users-return-22456-mr_kernel=163@subversion.apache.org] On > Behalf Of Philip Martin > Sent: Tuesday, November 04, 2014 7:27 PM > To: Chao.Guan > Cc: users@subversion.apache.org > Subject: Re: An error occurred during decompression > > "Chao.Guan" writes: > > > I am using TortoiseSVN 1.8.7, Build 25475 - 64 Bit on my Win7. I > > happened to see this information while updating contents: "ra_serf: An > > error occurred during decompression". > > > > I have searched the source code of TortoiseSVN 1.8.7 but didn't find > > any related code about it. > > > > I can't locate which commit cause the problem because there are about > > 100 commit and each commit has 40-50M and plenty of files. > > Can you guys give me some hints? What caused this error? What can I do > > to fix it? > > > > By the way, one of my colleagues is using TortoiseSVN 1.7.11 on Win7, > > he has this problem: "REPIRT of '/svn/st/!svn/vcc/default': Could not > > read chunk > > size: Secure connection truncated". Maybe those two error reports has > > the same root cause. Also, I can't find the related source code. > > > > Guys, help me with that, please! > > http://svn.haxx.se/dev/archive-2014-10/0004.shtml > > There is a serf bug that causes an error on checkout/update bigger than > 4GB: > This is weird, I get this error when I update a single folder of my working copy. The whole working copy is about 40G, but the folder is only 814M, why do I get the error then? > svn: E120104: ra_serf: An error occurred during decompression > > This was fixed in serf 1.3.8. You may be able to work around this bug by > disabling skelta mode on the client: > > http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default > > You can also work around the bug by disabling HTTP compression on the client > or the server. However if the server is Apache 2.2 and you disable HTTP > compression on the client while it remains enabled on the server you may > trigger an Apache bug: > > 1.8 client: > svn: E120106: ra_serf: The server sent a truncated HTTP response body. > > 1.7 client: > svn: E175002: REPORT of '...': Could not read chunk size: connection was > closed by server > > The Apache bug is a server crash so one user may see the error when some > other user triggers the bug. The Apache bug is fixed in 2.4. You can work > around the Apache bug by disabling HTTP compression on the server. > > Note HTTP compression is distinct from the deltas that Subversion uses > between client and server. Disabling HTTP compression does not stop > Subversion clients sending/receiving deltas. Disabling HTTP compression will > mostly affect non-Subversion clients such as web browsers. > > -- > Philip Martin | Subversion Committer > WANdisco // *Non-Stop Data*
