{"thread":{"id":"34359","subject":"Re: git-svn \"Temp file with moniker 'svn_delta' already in use\" and skelta mode","startedAt":"2013-07-06T00:34:23Z","lastAt":"2013-07-06T07:30:39Z","messageCount":5,"participants":["Branko Čibej","Daniel Shahaf","Bert Huijben"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"222656","messageId":"51D7660F.6070901@wandisco.com","threadId":"34359","inReplyTo":"kr7il5$n0p$1@ger.gmane.org","subject":"Re: git-svn \"Temp file with moniker 'svn_delta' already in use\" and skelta mode","fromName":"Branko Čibej","fromEmail":"brane@wandisco.com","sentAt":"2013-07-06T00:34:23Z","receivedAt":"2013-07-06T00:34:23Z","isPatch":false,"sender":{"key":"brane@wandisco.com","avatar":null},"body":"[Copying dev@ because it's related to a known issue that we document\nmore loudly.]\n\nOn 06.07.2013 00:51, David Rothenberger wrote:\n> I cannot reproduce this problem using command-line tools, but I was\n> able to do a trace of git-svn when it is failing and it looks to me\n> that the problem is in the order in which the SVN::Delta::Editor\n> (svn_delta_editor_t) function are being called.\n>\n> The order I see is:\n>  1. open_root\n>  2. open_directory\n>  3. add_file\n>  4. apply_textdelta\n>  5. add_file\n>  6. apply_textdelta\n>\n> The git-svn code is expecting a close_file call before the add_file\n> call in #5. It appears to me that the svn_delta_editor_t API [1]\n> requires this close_file call. It looks to me like this is Issue\n> #2932 [2].\n\nIndeed it is.\n\nAnd it is actually documented here:\n\nhttps://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/ra001.txt\n\nand mentioned here:\n\nhttp://subversion.apache.org/docs/release-notes/1.7.html#svnrdump\nIn other words, this is a limitation of the Serf-based backend that has\nbeen around since Subversion 1.4. I'm aware that it isn't documented as\nwell as it should be, but the bulk-mode workaround exists in part as a\nworkaround for that, effectively disabling the more efficient HTTPv2\nprotocol.\n\nIn the meantime, it might be a good idea to relax the restrictions in\ngit-svn to account for the way the HTTPv2 protocol works.\n\n-- Brane\n\n-- \nBranko Čibej | Director of Subversion\nWANdisco // Non-Stop Data\ne. brane@wandisco.com\n"},{"id":"222659","messageId":"20130706020407.GA26200@minotaur.apache.org","threadId":"34359","inReplyTo":"51D7660F.6070901@wandisco.com","subject":"Re: git-svn \"Temp file with moniker 'svn_delta' already in use\" and skelta mode","fromName":"Daniel Shahaf","fromEmail":"danielsh@apache.org","sentAt":"2013-07-06T02:04:07Z","receivedAt":"2013-07-06T02:04:07Z","isPatch":false,"sender":{"key":"danielsh@apache.org","avatar":null},"body":"On Sat, Jul 06, 2013 at 02:34:23AM +0200, Branko Čibej wrote:\n> http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump\n> In other words, this is a limitation of the Serf-based backend that has\n> been around since Subversion 1.4. I'm aware that it isn't documented as\n> well as it should be, but the bulk-mode workaround exists in part as a\n> workaround for that, effectively disabling the more efficient HTTPv2\n> protocol.\n\nIs it possible to set \"SVNAllowBulkUpdates Prefer\" on a per-client basis?\n\nThat would require two things: (1) for git-svn to identify itself as such via\nthe User-Agent string, (2) for httpd to support making the SVNAllowBulkUpdates\ndirective conditional on a request header.\n"},{"id":"222660","messageId":"20130706021545.GA39322@minotaur.apache.org","threadId":"34359","inReplyTo":"20130706020407.GA26200@minotaur.apache.org","subject":"Re: git-svn \"Temp file with moniker 'svn_delta' already in use\" and skelta mode","fromName":"Daniel Shahaf","fromEmail":"danielsh@apache.org","sentAt":"2013-07-06T02:15:45Z","receivedAt":"2013-07-06T02:15:45Z","isPatch":false,"sender":{"key":"danielsh@apache.org","avatar":null},"body":"On Sat, Jul 06, 2013 at 02:04:07AM +0000, Daniel Shahaf wrote:\n> On Sat, Jul 06, 2013 at 02:34:23AM +0200, Branko Čibej wrote:\n> > http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump\n> > In other words, this is a limitation of the Serf-based backend that has\n> > been around since Subversion 1.4. I'm aware that it isn't documented as\n> > well as it should be, but the bulk-mode workaround exists in part as a\n> > workaround for that, effectively disabling the more efficient HTTPv2\n> > protocol.\n> \n> Is it possible to set \"SVNAllowBulkUpdates Prefer\" on a per-client basis?\n\nActually, I'm approaching this from the wrong direction.  We have an\n'http-bulk-updates' config knob, so an immediate workaround is for git-svn\nto install --config-option=servers:global:http-bulk-updates=on in their client\ncontext.\n"},{"id":"222665","messageId":"51D79BDD.5020106@wandisco.com","threadId":"34359","inReplyTo":"51D7660F.6070901@wandisco.com","subject":"Re: git-svn \"Temp file with moniker 'svn_delta' already in use\" and skelta mode","fromName":"Branko Čibej","fromEmail":"brane@wandisco.com","sentAt":"2013-07-06T04:23:57Z","receivedAt":"2013-07-06T04:23:57Z","isPatch":false,"sender":{"key":"brane@wandisco.com","avatar":null},"body":"On 06.07.2013 02:34, Branko Čibej wrote:\n> In the meantime, it might be a good idea to relax the restrictions in\n> git-svn to account for the way the HTTPv2 protocol works.\n\nBy the way, this section of the 1.8 release notes is relevant:\n\nhttp://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted\n\nIn 1.8 there is a client-side configuration option called\nhttp-bulk-updates that controls how the client will request data from\nthe server. It can be set in the ~/.subversion/servers file, or on the\ncomand-line by the option\n\n    --config-option=servers:global:http-bulk-updates=on\n\nor, of course, in the client API context. git-svn should probably do the\nlatter as a simple workaround.\n\n-- Brane\n\n-- \nBranko Čibej | Director of Subversion\nWANdisco // Non-Stop Data\ne. brane@wandisco.com\n"},{"id":"222668","messageId":"51d7c848.0a0cb50a.6b9a.0884@mx.google.com","threadId":"34359","inReplyTo":"51D7660F.6070901@wandisco.com","subject":"Re: git-svn \"Temp file with moniker 'svn_delta' already in use\" and skelta mode","fromName":"Bert Huijben","fromEmail":"bert@qqmail.nl","sentAt":"2013-07-06T07:30:39Z","receivedAt":"2013-07-06T07:30:39Z","isPatch":false,"sender":{"key":"bert@qqmail.nl","avatar":"https://gravatar.com/avatar/3eb6d66fbca2e83b0c493dce9c96e6cc40e2d7983403900ac34453dfcc80bc05?d=mp&s=160"},"body":"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.\n\n\nSerf was only the first driver to do it this way in the other direction.\n\n\nBert\n\n\n\n\n\n\nSent from Windows Mail\n\n\n\n\n\nFrom: Branko Čibej\nSent: ‎Saturday‎, ‎July‎ ‎6‎, ‎2013 ‎2‎:‎34‎ ‎AM\nTo: users@subversion.apache.org\nCc: Subversion Development; git@vger.kernel.org\n\n\n\n\n[Copying dev@ because it's related to a known issue that we document more loudly.]\n\nOn 06.07.2013 00:51, David Rothenberger wrote: \n\nI cannot reproduce this problem using command-line tools, but I was\nable to do a trace of git-svn when it is failing and it looks to me\nthat the problem is in the order in which the SVN::Delta::Editor\n(svn_delta_editor_t) function are being called.\n\nThe order I see is:\n 1. open_root\n 2. open_directory\n 3. add_file\n 4. apply_textdelta\n 5. add_file\n 6. apply_textdelta\n\nThe git-svn code is expecting a close_file call before the add_file\ncall in #5. It appears to me that the svn_delta_editor_t API [1]\nrequires this close_file call. It looks to me like this is Issue\n#2932 [2].\n\nIndeed it is.\n\nAnd it is actually documented here:\n\nhttps://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/ra001.txt\n\nand mentioned here:\n\nhttp://subversion.apache.org/docs/release-notes/1.7.html#svnrdump\n\n\nIn 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.\n\nIn the meantime, it might be a good idea to relax the restrictions in git-svn to account for the way the HTTPv2 protocol works.\n\n-- Brane\n\n\n-- \nBranko Čibej | Director of Subversion \nWANdisco // Non-Stop Data \ne. brane@wandisco.com"}]}