# Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode 5 messages from 2013-07-06 to 2013-07-06. Participants: Branko Čibej, Daniel Shahaf, Bert Huijben. Thread: https://gitlist.dev/t/34359 ## Branko Čibej, 2013-07-06 00:34 Subject: Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode Message-ID: <51D7660F.6070901@wandisco.com> URL: https://gitlist.dev/e/51D7660F.6070901%40wandisco.com In-Reply-To: ``` [Copying dev@ because it's related to a known issue that we document more loudly.] On 06.07.2013 00:51, David Rothenberger wrote: > I cannot reproduce this problem using command-line tools, but I was > able to do a trace of git-svn when it is failing and it looks to me > that the problem is in the order in which the SVN::Delta::Editor > (svn_delta_editor_t) function are being called. > > The order I see is: > 1. open_root > 2. open_directory > 3. add_file > 4. apply_textdelta > 5. add_file > 6. apply_textdelta > > The git-svn code is expecting a close_file call before the add_file > call in #5. It appears to me that the svn_delta_editor_t API [1] > requires this close_file call. It looks to me like this is Issue > #2932 [2]. Indeed it is. And it is actually documented here: https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/ra001.txt and mentioned here: http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump In other words, this is a limitation of the Serf-based backend that has been around since Subversion 1.4. I'm aware that it isn't documented as well as it should be, but the bulk-mode workaround exists in part as a workaround for that, effectively disabling the more efficient HTTPv2 protocol. In the meantime, it might be a good idea to relax the restrictions in git-svn to account for the way the HTTPv2 protocol works. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. brane@wandisco.com ``` ## Daniel Shahaf, 2013-07-06 02:04 Subject: Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode Message-ID: <20130706020407.GA26200@minotaur.apache.org> URL: https://gitlist.dev/e/20130706020407.GA26200%40minotaur.apache.org In-Reply-To: <51D7660F.6070901@wandisco.com> ``` On Sat, Jul 06, 2013 at 02:34:23AM +0200, Branko Čibej wrote: > http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump > In other words, this is a limitation of the Serf-based backend that has > been around since Subversion 1.4. I'm aware that it isn't documented as > well as it should be, but the bulk-mode workaround exists in part as a > workaround for that, effectively disabling the more efficient HTTPv2 > protocol. Is it possible to set "SVNAllowBulkUpdates Prefer" on a per-client basis? That would require two things: (1) for git-svn to identify itself as such via the User-Agent string, (2) for httpd to support making the SVNAllowBulkUpdates directive conditional on a request header. ``` ## Daniel Shahaf, 2013-07-06 02:15 Subject: Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode Message-ID: <20130706021545.GA39322@minotaur.apache.org> URL: https://gitlist.dev/e/20130706021545.GA39322%40minotaur.apache.org In-Reply-To: <20130706020407.GA26200@minotaur.apache.org> ``` On Sat, Jul 06, 2013 at 02:04:07AM +0000, Daniel Shahaf wrote: > On Sat, Jul 06, 2013 at 02:34:23AM +0200, Branko Čibej wrote: > > http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump > > In other words, this is a limitation of the Serf-based backend that has > > been around since Subversion 1.4. I'm aware that it isn't documented as > > well as it should be, but the bulk-mode workaround exists in part as a > > workaround for that, effectively disabling the more efficient HTTPv2 > > protocol. > > Is it possible to set "SVNAllowBulkUpdates Prefer" on a per-client basis? Actually, I'm approaching this from the wrong direction. We have an 'http-bulk-updates' config knob, so an immediate workaround is for git-svn to install --config-option=servers:global:http-bulk-updates=on in their client context. ``` ## Branko Čibej, 2013-07-06 04:23 Subject: Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode Message-ID: <51D79BDD.5020106@wandisco.com> URL: https://gitlist.dev/e/51D79BDD.5020106%40wandisco.com In-Reply-To: <51D7660F.6070901@wandisco.com> ``` On 06.07.2013 02:34, Branko Čibej wrote: > In the meantime, it might be a good idea to relax the restrictions in > git-svn to account for the way the HTTPv2 protocol works. By the way, this section of the 1.8 release notes is relevant: http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted In 1.8 there is a client-side configuration option called http-bulk-updates that controls how the client will request data from the server. It can be set in the ~/.subversion/servers file, or on the comand-line by the option --config-option=servers:global:http-bulk-updates=on or, of course, in the client API context. git-svn should probably do the latter as a simple workaround. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. brane@wandisco.com ``` ## Bert Huijben, 2013-07-06 07:30 Subject: Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode Message-ID: <51d7c848.0a0cb50a.6b9a.0884@mx.google.com> URL: https://gitlist.dev/e/51d7c848.0a0cb50a.6b9a.0884%40mx.google.com In-Reply-To: <51D7660F.6070901@wandisco.com> ``` Note that the commit logic in libsvn_client uses exactly the same driver pattern, but even in a more extreme way: it opens all nodes before closing the first file that will receive content changes. Serf was only the first driver to do it this way in the other direction. Bert Sent from Windows Mail From: Branko Čibej Sent: ‎Saturday‎, ‎July‎ ‎6‎, ‎2013 ‎2‎:‎34‎ ‎AM To: users@subversion.apache.org Cc: Subversion Development; git@vger.kernel.org [Copying dev@ because it's related to a known issue that we document more loudly.] On 06.07.2013 00:51, David Rothenberger wrote: I cannot reproduce this problem using command-line tools, but I was able to do a trace of git-svn when it is failing and it looks to me that the problem is in the order in which the SVN::Delta::Editor (svn_delta_editor_t) function are being called. The order I see is: 1. open_root 2. open_directory 3. add_file 4. apply_textdelta 5. add_file 6. apply_textdelta The git-svn code is expecting a close_file call before the add_file call in #5. It appears to me that the svn_delta_editor_t API [1] requires this close_file call. It looks to me like this is Issue #2932 [2]. Indeed it is. And it is actually documented here: https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/ra001.txt and mentioned here: http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump In other words, this is a limitation of the Serf-based backend that has been around since Subversion 1.4. I'm aware that it isn't documented as well as it should be, but the bulk-mode workaround exists in part as a workaround for that, effectively disabling the more efficient HTTPv2 protocol. In the meantime, it might be a good idea to relax the restrictions in git-svn to account for the way the HTTPv2 protocol works. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. brane@wandisco.com ```