{"thread":{"id":"35337","subject":"Fwd: Error with git-svn pushing a rename","startedAt":"2013-11-14T15:26:11Z","lastAt":"2014-01-17T19:23:15Z","messageCount":27,"participants":["Benjamin Pabst","Andreas Stricker","Jonathan Nieder","Roman Kagan","Thomas Rast","Eric Wong","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"230628","messageId":"CAM-uYMiK4wkQyGJLemSAbNwHJNoH-k8Zv0W2yBtnTCbsFLj8Fg@mail.gmail.com","threadId":"35337","inReplyTo":"CAM-uYMigCTK=j3HkyT0F=jtDoDERdtkpZiTXRvBhSHJW3edJ-w@mail.gmail.com","subject":"Fwd: Error with git-svn pushing a rename","fromName":"Benjamin Pabst","fromEmail":"benjamin.pabst85@gmail.com","sentAt":"2013-11-14T15:26:11Z","receivedAt":"2013-11-14T15:26:11Z","isPatch":false,"sender":{"key":"benjamin.pabst85@gmail.com","avatar":null},"body":"Hi guys,\n\nI'm using git as a subversion client, which works great so far. But\ntoday I tried to push back a rename to the subversion server, which\nresulted in the following error:\n\nperl: subversion/libsvn_subr/dirent_uri.c:2489:\nsvn_fspath__skip_ancestor: Assertion\n`svn_fspath__is_canonical(child_fspath)' failed.\nerror: git-svn died of signal 6\n\nAfter searching the web I found a similar problem at stackoverflow:\nhttp://stackoverflow.com/questions/17693255/git-svn-dcommit-fails-because-of-assertion-error-svn-fspath-is-canonicalchildj\n\nSo I tried to downgrade subversion (1.7.x) which didn't help. Then I\nalso tried to downgrade git (1.7.x) which resulted in a different\nerror:\n'tempfile' can't be called as a method at\n/usr/share/perl5/vendor_perl/Git.pm line 1042.\n\nSo I updated both packages to the current version:\n$ git --version\ngit version 1.8.4.2\n\n$ svn --version\nsvn, version 1.8.3 (r1516576)\n   compiled Sep 13 2013, 00:34:15 on x86_64-unknown-linux-gnu\n\nCopyright (C) 2013 The Apache Software Foundation.\nThis software consists of contributions made by many people;\nsee the NOTICE file for more information.\nSubversion is open source software, see http://subversion.apache.org/\n\nThe following repository access (RA) modules are available:\n\n* ra_svn : Module for accessing a repository using the svn network protocol.\n  - with Cyrus SASL authentication\n  - handles 'svn' scheme\n* ra_local : Module for accessing a repository on local disk.\n  - handles 'file' scheme\n* ra_serf : Module for accessing a repository via WebDAV protocol using serf.\n  - using serf 1.3.1\n  - handles 'http' scheme\n  - handles 'https' scheme\n\nBut now I'm back at the first error. Just for completeness, the error\noccurs on the following operation:\n$ git svn dcommit\nCommitting to https://xxxxx ...\nR xxxx/xxxx/SomeFile => xxxx/xxxx/SomeOtherFile\nperl: subversion/libsvn_subr/dirent_uri.c:2489:\nsvn_fspath__skip_ancestor: Assertion\n`svn_fspath__is_canonical(child_fspath)' failed.\nerror: git-svn died of signal 6\n\nAny ideas on handling this error?\n\nSorry for the (wrongly sent) first mail (incomplete).\n\nWould be happy to hear from you.\n\nGreetings\nBen\n"},{"id":"230665","messageId":"5285CE6C.2030609@futurelab.ch","threadId":"35337","inReplyTo":"CAM-uYMiK4wkQyGJLemSAbNwHJNoH-k8Zv0W2yBtnTCbsFLj8Fg@mail.gmail.com","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Andreas Stricker","fromEmail":"astricker@futurelab.ch","sentAt":"2013-11-15T07:34:04Z","receivedAt":"2013-11-15T07:34:04Z","isPatch":false,"sender":{"key":"astricker@futurelab.ch","avatar":"https://gravatar.com/avatar/007ac93f9abc20ee78c5169783fcf3f065d470d6b53d47050e30cf7ebad5025b?d=mp&s=160"},"body":"Hi\n\n> But today I tried to push back a rename to the subversion server,\n> which resulted in the following error:>\n> perl: subversion/libsvn_subr/dirent_uri.c:2489:\n> svn_fspath__skip_ancestor: Assertion\n> `svn_fspath__is_canonical(child_fspath)' failed.\n> error: git-svn died of signal 6\n\nI also observed this issue with a rename. My workaround was to downgrade\nsubversion to 1.7.x. That worked, but I'm searching for a real solution.\n\n> After searching the web I found a similar problem at stackoverflow:\n>\nhttp://stackoverflow.com/questions/17693255/git-svn-dcommit-fails-because-of-assertion-error-svn-fspath-is-canonicalchildj\n\nI'll add this one to the list: https://trac.macports.org/ticket/39986\n\nIt looks like I'm not the only one experiencing this.\n\nRegards, Andy\n"},{"id":"230679","messageId":"5286235D.9060602@futurelab.ch","threadId":"35337","inReplyTo":"CAM-uYMgn4SGqurqRG-RDiicLxpf9NfTPUvNn9FaFUUbxFRJsZw@mail.gmail.com","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Andreas Stricker","fromEmail":"astricker@futurelab.ch","sentAt":"2013-11-15T13:36:29Z","receivedAt":"2013-11-15T13:36:29Z","isPatch":false,"sender":{"key":"astricker@futurelab.ch","avatar":"https://gravatar.com/avatar/007ac93f9abc20ee78c5169783fcf3f065d470d6b53d47050e30cf7ebad5025b?d=mp&s=160"},"body":"Hi Benjamin\n\n> thanks for your link. Can you give me the exact version you\n> downgraded svn to?\n\nsvn, Version 1.7.10 (r1485443)\n\nI tried to reproduce the problem with git version 1.8.4.2 and\nSubversion version 1.8.4 (r1534716) with a fresh and pristine\nsubversion repo and a git-svn clone of it: I didn't manage to\nreproduce the rename issue. Then I switched subversion back to\n1.7.10, created both the repo and the git-svn clone, switched\nagaint to 1.8.4.2 and then got an error. Unfortunately I didn't\ncheck if the subversion perlbindings were regenerated, so I'm\nnot exactly sure. I'll repeat the test again, as soon I've find\nthe time.\n\nIt looks like a fresh git svn clone may fix the problem.\n\nRegards, Andy\n"},{"id":"230690","messageId":"20131115225316.GF27781@google.com","threadId":"35337","inReplyTo":"5286235D.9060602@futurelab.ch","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-11-15T22:53:16Z","receivedAt":"2013-11-15T22:53:16Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Andreas Stricker wrote:\n\n> svn, Version 1.7.10 (r1485443)\n>\n> I tried to reproduce the problem with git version 1.8.4.2 and\n> Subversion version 1.8.4 (r1534716) with a fresh and pristine\n> subversion repo and a git-svn clone of it: I didn't manage to\n> reproduce the rename issue. Then I switched subversion back to\n> 1.7.10, created both the repo and the git-svn clone, switched\n> againt to 1.8.4.2 and then got an error. Unfortunately I didn't\n> check if the subversion perlbindings were regenerated, so I'm\n> not exactly sure.\n[...]\n> It looks like a fresh git svn clone may fix the problem.\n\nYuck.\n\nCan you give an exact sequence of steps (including \"Upgrade Subversion\nat this step\") to reproduce the problem?  That would help immensely\n--- if at all possible, I would very much like to keep existing\ngit-svn repos working on upgrade.\n\nThanks for your work so far on this.\n\nSincerely,\nJonathan\n"},{"id":"230733","messageId":"52894951.7000303@futurelab.ch","threadId":"35337","inReplyTo":"20131115225316.GF27781@google.com","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Andreas Stricker","fromEmail":"astricker@futurelab.ch","sentAt":"2013-11-17T22:55:13Z","receivedAt":"2013-11-17T22:55:13Z","isPatch":false,"sender":{"key":"astricker@futurelab.ch","avatar":"https://gravatar.com/avatar/007ac93f9abc20ee78c5169783fcf3f065d470d6b53d47050e30cf7ebad5025b?d=mp&s=160"},"body":"Hi Jonathan\n\n> Can you give an exact sequence of steps (including \"Upgrade Subversion\n> at this step\") to reproduce the problem?  That would help immensely\n> --- if at all possible, I would very much like to keep existing\n> git-svn repos working on upgrade.\n\nOf course. I've attached a text file with the commands required to\nreproduce this error.\n\n>From my experiments it looks like after the subversion is upgraded\nto 1.8 the problem only occurs if \"git svn fetch\" fetches new changes\nfrom the subversion repository. Without changes in upstream subversion\nrepository I couldn't reproduce the error. And a rename is required too.\n\nHope this helps.\n\nRegards, Andy\n\n\nandy@m:r $ git\n-bash: /opt/local/bin/git: No such file or directory\nandy@m:r $ svn\n-bash: /opt/local/bin/svn: No such file or directory\nandy@m:r $ sudo port install subversion--->  Computing dependencies for subversion\n--->  Fetching archive for subversion\n--->  Attempting to fetch subversion-1.7.10_1.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/subversion\n--->  Attempting to fetch subversion-1.7.10_1.darwin_11.x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/subversion\n--->  Installing subversion @1.7.10_1\n--->  Activating subversion @1.7.10_1\n--->  Cleaning subversion\n--->  Updating database of binaries: 100.0%\n--->  Scanning binaries for linking errors: 100.0%\n--->  Found 15 broken file(s), matching files to ports\n--->  Found 1 broken port(s), determining rebuild order\n--->  Rebuilding in order\n     subversion @1.7.10 \n--->  Computing dependencies for subversion\n--->  Cleaning subversion\n--->  Scanning binaries for linking errors: 100.0%\n--->  Found 15 broken file(s), matching files to ports\n--->  Found 1 broken port(s), determining rebuild order\n--->  Rebuilding in order\n     subversion @1.7.10 \n--->  Computing dependencies for subversion\n--->  Fetching distfiles for subversion\n--->  Verifying checksums for subversion\n--->  Extracting subversion\n--->  Applying patches to subversion\n--->  Configuring subversion\n--->  Building subversion\n--->  Staging subversion into destroot\n--->  Deactivating subversion @1.7.10_1\n--->  Cleaning subversion\n--->  Uninstalling subversion @1.7.10_1\n--->  Cleaning subversion\n--->  Computing dependencies for subversion\n--->  Installing subversion @1.7.10_1\n--->  Activating subversion @1.7.10_1\n--->  Cleaning subversion\n--->  Updating database of binaries: 100.0%\n--->  Scanning binaries for linking errors: 100.0%\n--->  No broken files found.\nandy@m:r $ sudo port install git-core +bash_completion +credential_osxkeychain +doc +pcre +python27 +svn\nPassword:\n--->  Computing dependencies for git-core\n--->  Dependencies to be installed: p5.12-svn-simple subversion-perlbindings-5.12\n--->  Fetching archive for subversion-perlbindings-5.12\n--->  Attempting to fetch subversion-perlbindings-5.12-1.7.10_0.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/subversion-perlbindings-5.12\n--->  Attempting to fetch subversion-perlbindings-5.12-1.7.10_0.darwin_11.x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/subversion-perlbindings-5.12\n--->  Installing subversion-perlbindings-5.12 @1.7.10_0\n--->  Activating subversion-perlbindings-5.12 @1.7.10_0\n--->  Cleaning subversion-perlbindings-5.12\n--->  Fetching archive for p5.12-svn-simple\n--->  Attempting to fetch p5.12-svn-simple-0.280.0_4.darwin_11.noarch.tbz2 from http://lil.fr.packages.macports.org/p5.12-svn-simple\n--->  Attempting to fetch p5.12-svn-simple-0.280.0_4.darwin_11.noarch.tbz2.rmd160 from http://lil.fr.packages.macports.org/p5.12-svn-simple\n--->  Installing p5.12-svn-simple @0.280.0_4\n--->  Activating p5.12-svn-simple @0.280.0_4\n--->  Cleaning p5.12-svn-simple\n--->  Fetching archive for git-core\n--->  Attempting to fetch git-core-1.8.4.2_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/git-core\n--->  Attempting to fetch git-core-1.8.4.2_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn.darwin_11.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/git-core\n--->  Attempting to fetch git-core-1.8.4.2_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn.darwin_11.x86_64.tbz2 from http://packages.macports.org/git-core\n--->  Fetching distfiles for git-core\n--->  Verifying checksums for git-core\n--->  Extracting git-core\n--->  Applying patches to git-core\n--->  Configuring git-core\n--->  Building git-core\n--->  Staging git-core into destroot\n--->  Installing git-core @1.8.4.2_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn\n--->  Activating git-core @1.8.4.2_0+bash_completion+credential_osxkeychain+doc+pcre+python27+svn\n--->  Cleaning git-core\n--->  Updating database of binaries: 100.0%\n--->  Scanning binaries for linking errors: 100.0%\n--->  No broken files found.\nandy@m:r $ git version\ngit version 1.8.4.2\nandy@m:r $ svn --version |head -n2svn, Version 1.7.10 (r1485443)\n   übersetzt Nov 17 2013, 22:58:41\nandy@m:r $ svnadmin create svnrepo\nandy@m:r $ svn checkout file://$PWD/svnrepo svnwork\nAusgecheckt, Revision 0.\nandy@m:r $ cd svnwork/\nandy@m:svnwork $ echo 'original content' > content.txt\nandy@m:svnwork $ git add content.txt \nfatal: Not a git repository (or any of the parent directories): .git\nandy@m:svnwork $ svn add content.txt \nA         content.txt\nandy@m:svnwork $ svn commit -m 'initial commit'\nHinzufügen     content.txt\nÜbertrage Daten .\nRevision 1 übertragen.\nandy@m:svnwork $ cd ..\nandy@m:r $ git svn clone file://$PWD/svnrepo gitwork\nInitialisierte leeres Git-Repository in /private/tmp/r/gitwork/.git/\n\tA\tcontent.txt\nr1 = e27a31ad2100f7080dcb2c63eaf8bc7b74130bd5 (refs/remotes/git-svn)\nChecked out HEAD:\n  file:///tmp/r/svnrepo r1\nandy@m:r $ cd gitwork/\nandy@m:gitwork (master) $ echo 'another line' >> content.txt \nandy@m:gitwork (master) $ echo 'new file' > newfile.txt\nandy@m:gitwork (master) $ git add content.txt newfile.txt \nandy@m:gitwork (master) $ git commit -m 'changed content'\n[master cd1a8ee] changed content\n 2 files changed, 2 insertions(+)\n create mode 100644 newfile.txt\nandy@m:gitwork (master) $ git svn dcommit\nCommitting to file:///tmp/r/svnrepo ...\n\tA\tnewfile.txt\n\tM\tcontent.txt\nCommitted r2\n\tA\tnewfile.txt\n\tM\tcontent.txt\nr2 = 4bc308cdb2684887844e8dde973c9aa26b80e2ca (refs/remotes/git-svn)\nNo changes between cd1a8eeeba8cc2cd4f452eba922a09780658e096 and refs/remotes/git-svn\nResetting to the latest refs/remotes/git-svn\nandy@m:gitwork (master) $ echo 'switch subversion 1.7 in local port repo off'\nswitch subversion 1.7 in local port repo off\nandy@m:gitwork (master) $ sudo port -v upgrade subversion subversion-perlbindings-5.12\nPassword:\n--->  Computing dependencies for subversion.\n--->  Fetching archive for subversion\n--->  subversion-1.8.4_1.darwin_11.x86_64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified\n--->  Attempting to fetch subversion-1.8.4_1.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/subversion\n--->  Attempting to fetch subversion-1.8.4_1.darwin_11.x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/subversion\n--->  Installing subversion @1.8.4_1\n--->  Cleaning subversion\n--->  Removing work directory for subversion\n--->  Computing dependencies for subversion.\n--->  Deactivating subversion @1.7.10_1\n--->  Cleaning subversion\n--->  Removing work directory for subversion\n--->  Activating subversion @1.8.4_1\n--->  Cleaning subversion\n--->  Removing work directory for subversion\n--->  Computing dependencies for subversion-perlbindings-5.12.\n--->  Fetching archive for subversion-perlbindings-5.12\n--->  subversion-perlbindings-5.12-1.8.4_0.darwin_11.x86_64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified\n--->  Attempting to fetch subversion-perlbindings-5.12-1.8.4_0.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/subversion-perlbindings-5.12\n--->  Attempting to fetch subversion-perlbindings-5.12-1.8.4_0.darwin_11.x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/subversion-perlbindings-5.12\n--->  Installing subversion-perlbindings-5.12 @1.8.4_0\n--->  Cleaning subversion-perlbindings-5.12\n--->  Removing work directory for subversion-perlbindings-5.12\n--->  Computing dependencies for subversion-perlbindings-5.12.\n--->  Deactivating subversion-perlbindings-5.12 @1.7.10_0\n--->  Cleaning subversion-perlbindings-5.12\n--->  Removing work directory for subversion-perlbindings-5.12\n--->  Activating subversion-perlbindings-5.12 @1.8.4_0\n--->  Cleaning subversion-perlbindings-5.12\n--->  Removing work directory for subversion-perlbindings-5.12\n--->  Updating database of binaries: 100.0%\n--->  Scanning binaries for linking errors: 100.0%\n--->  No broken files found.\nandy@m:gitwork (master) $ git version\ngit version 1.8.4.2\nandy@m:gitwork (master) $ svn --version |head -n2\nsvn, Version 1.8.4 (r1534716)\n   übersetzt am Nov  1 2013, um 14:41:52 auf x86_64-apple-darwin11.4.2\nandy@m:gitwork (master) $ cd ../svnwork/\nandy@m:svnwork $ svn up\nsvn: E155036: Siehe Kommando »svn upgrade«\nsvn: E155036: Die Arbeitskopie in »/private/tmp/r/svnwork«\nist zu alt (Format 29) für die Verwendung mit der Version »1.8.4 (r1534716)« (erwartet Format 31). Sie müssen die Arbeitskopie zuerst in ein neues Format bringen.\n\nandy@m:svnwork $ svn upgrade\nIn neues Format gebracht: ».«\nandy@m:svnwork $ svn up\nAktualisiere ».«:\nU    content.txt\nA    newfile.txt\nAktualisiert zu Revision 2.\nandy@m:svnwork $ cd ../gitwork/\nandy@m:gitwork (master) $ git svn fetch\nandy@m:gitwork (master) $ echo 'yet another line' >> content.txt \nandy@m:gitwork (master) $ git mv newfile.txt somefile.txt\nandy@m:gitwork (master) $ git add content.txt \nandy@m:gitwork (master) $ git commit -m 'changed content, moved file'\n[master c92f414] changed content, moved file\n 2 files changed, 1 insertion(+)\n rename newfile.txt => somefile.txt (100%)\nandy@m:gitwork (master) $ git svn dcommit\nCommitting to file:///tmp/r/svnrepo ...\n\tR\tnewfile.txt => somefile.txt\n\tM\tcontent.txt\nCommitted r3\n\tD\tnewfile.txt\n\tM\tcontent.txt\n\tA\tsomefile.txt\nW: -empty_dir: newfile.txt\nr3 = e46693b582c5c85710a9a3ea5179ac8fef2d2b22 (refs/remotes/git-svn)\nNo changes between c92f4143403de8088363551f92bca30499842a4c and refs/remotes/git-svn\nResetting to the latest refs/remotes/git-svn\nandy@m:gitwork (master) $ cd ../svnwork/\nandy@m:svnwork $ svn up\nAktualisiere ».«:\nD    newfile.txt\nA    somefile.txt\nU    content.txt\nAktualisiert zu Revision 3.\nandy@m:svnwork $ ls\ncontent.txt  somefile.txt\nandy@m:svnwork $ echo 'a line from svn repo' >> content.txt \nandy@m:svnwork $ echo 'a line from svn repo' >> somefile.txt \nandy@m:svnwork $ svn commit -m 'added something from svn repo'\nSende              content.txt\nSende              somefile.txt\nÜbertrage Daten ..\nRevision 4 übertragen.\nandy@m:svnwork $ cd ../gitwork/\nandy@m:gitwork (master) $ git svn rebase\n\tM\tsomefile.txt\n\tM\tcontent.txt\nr4 = b629f9c35a718e99a811d7fd0ada607687aebde3 (refs/remotes/git-svn)\nZunächst wird der Branch zurückgespult, um Ihre Änderungen\ndarauf neu anzuwenden...\nmaster zu refs/remotes/git-svn vorgespult.\nandy@m:gitwork (master) $ echo 'add more content' >> content.txt \nandy@m:gitwork (master) $ git add content.txt \nandy@m:gitwork (master) $ git mv somefile.txt anyfile.txt\nandy@m:gitwork (master) $ git commit -m 'change more content'\n[master 453e050] change more content\n 2 files changed, 1 insertion(+)\n rename somefile.txt => anyfile.txt (100%)\nandy@m:gitwork (master) $ git svn dcommit\nCommitting to file:///tmp/r/svnrepo ...\n\tR\tsomefile.txt => anyfile.txt\n\tM\tcontent.txt\nCommitted r5\n\tD\tsomefile.txt\n\tA\tanyfile.txt\n\tM\tcontent.txt\nW: -empty_dir: somefile.txt\nr5 = e038ff05f796c6f79c63556d6a75a7e86976f060 (refs/remotes/git-svn)\nNo changes between 453e050c2f6e4ca0de11b42bd9329aff43ec3da0 and refs/remotes/git-svn\nResetting to the latest refs/remotes/git-svn\nandy@m:gitwork (master) $ cd ../svnwork/\nandy@m:svnwork $ svn up\nAktualisiere ».«:\nU    content.txt\nD    somefile.txt\nA    anyfile.txt\nAktualisiert zu Revision 5.\nandy@m:svnwork $ echo 'more svn content' >> content.txt \nandy@m:svnwork $ echo 'new content' > newfile.txt\nandy@m:svnwork $ svn add newfile.txt \nA         newfile.txt\nandy@m:svnwork $ svn commit -m 'more data from svn'\nSende              content.txt\nFüge hinzu         newfile.txt\nÜbertrage Daten ..\nRevision 6 übertragen.\nandy@m:svnwork $ cd ../gitwork/\nandy@m:gitwork (master) $ git svn fetch\n\tA\tnewfile.txt\n\tM\tcontent.txt\nr6 = f98167f128945f5045342366ac9a84d72873c479 (refs/remotes/git-svn)\nandy@m:gitwork (master) $ git mv anyfile.txt somefile.txt\nandy@m:gitwork (master) $ echo 'changed too' >> somefile.txt \nandy@m:gitwork (master) $ git add somefile.txt \nandy@m:gitwork (master) $ echo 'replaced content' > content.txt \nandy@m:gitwork (master) $ git add content.txt \nandy@m:gitwork (master) $ git commit -m 'did some changes' \n[master 0cb4cd8] did some changes\n 2 files changed, 2 insertions(+), 5 deletions(-)\n rename anyfile.txt => somefile.txt (71%)\nandy@m:gitwork (master) $ git svn dcommit\nCommitting to file:///tmp/r/svnrepo ...\n\tR\tanyfile.txt => somefile.txt\n\nERROR from SVN:\nTransaktion ist veraltet: Datei »/content.txt« ist veraltet\nW: 0cb4cd820d65cdf4d8a18146c54740e4af0dc533 and refs/remotes/git-svn differ, using rebase:\n:000000 100644 0000000000000000000000000000000000000000 cd42f7309485e8df6f795807835ee1ef9d875556 A\tanyfile.txt\n:100644 100644 3d69ed67cef70be1a2357dcaaffcd5cc34aaa7ce 58fc0689b4691eb02c737f7cc1faf5a860b2a1d9 M\tcontent.txt\n:000000 100644 0000000000000000000000000000000000000000 b66ba06d315d46280bb09d54614cc52d1677809f A\tnewfile.txt\n:100644 000000 949eb457147d5e2d187c4dd426b4a05df229900d 0000000000000000000000000000000000000000 D\tsomefile.txt\nZunächst wird der Branch zurückgespult, um Ihre Änderungen\ndarauf neu anzuwenden...\nWende an: did some changes\nVerwende Informationen aus der Staging-Area um einen Basisverzeichnis nachzustellen\nM\tcontent.txt\nFalle zurück zum Patchen der Basis und des 3-Wege-Merges...\nautomatischer Merge von somefile.txt\nautomatischer Merge von content.txt\nKONFLIKT (Inhalt): Merge-Konflikt in content.txt\nMerge der Änderungen fehlgeschlagen\nAnwendung des Patches fehlgeschlagen bei 0001 did some changes\nDie Kopie des fehlgeschlagenen Patches befindet sich in:\n   /tmp/r/gitwork/.git/rebase-apply/patch\n\nWenn Sie das Problem aufgelöst haben, führen Sie \"git rebase --continue\" aus.\nFalls Sie diesen Patch auslassen möchten, führen Sie stattdessen \"git rebase --skip\" aus.\nUm den ursprünglichen Branch wiederherzustellen und den Rebase abzubrechen,\nführen Sie \"git rebase --abort\" aus.\n\nrebase refs/remotes/git-svn: command returned error: 1\n\nandy@m:gitwork (master|REBASE 1/1) $ \n\n"},{"id":"230770","messageId":"CAM-uYMiSE-XxA7DSWQSwzZ2vwB_MP5gnxuTzEJ7Vw9LRj2nwWA@mail.gmail.com","threadId":"35337","inReplyTo":"5286235D.9060602@futurelab.ch","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Benjamin Pabst","fromEmail":"benjamin.pabst85@gmail.com","sentAt":"2013-11-18T17:59:49Z","receivedAt":"2013-11-18T17:59:49Z","isPatch":false,"sender":{"key":"benjamin.pabst85@gmail.com","avatar":null},"body":"Hi Andy,\n\nsadly I get the same error with a downgraded svn:\n\n$ git --version\ngit version 1.8.4.2\n$ svn --version\nsvn, version 1.7.10 (r1485443)\n   compiled Nov 18 2013, 18:43:16\n\nCopyright (C) 2013 The Apache Software Foundation.\nThis software consists of contributions made by many people; see the NOTICE\nfile for more information.\nSubversion is open source software, see http://subversion.apache.org/\n\nThe following repository access (RA) modules are available:\n\n* ra_svn : Module for accessing a repository using the svn network protocol.\n  - with Cyrus SASL authentication\n  - handles 'svn' scheme\n* ra_local : Module for accessing a repository on local disk.\n  - handles 'file' scheme\n* ra_serf : Module for accessing a repository via WebDAV protocol using serf.\n  - handles 'http' scheme\n  - handles 'https' scheme\n\n$ git svn dcommit\nCommitting to https://xxxxx.xxx/xxxxx ...\nR /some/file => /some/new/filename\nperl: subversion/libsvn_subr/dirent_uri.c:2500: svn_fspath__is_child:\nAssertion `svn_fspath__is_canonical(child_fspath)' failed.\nerror: git-svn died of signal 6\n\nAny idea what I should do next to get this working? I also tried with\na \"$ git svn rebase\" first, which throws no error (just an \"already\nup-to-date\")...\n\nThanks for your help!\n\nRegards\nBen\n\n2013/11/15 Andreas Stricker <astricker@futurelab.ch>:\n> Hi Benjamin\n>\n>> thanks for your link. Can you give me the exact version you\n>> downgraded svn to?\n>\n> svn, Version 1.7.10 (r1485443)\n>\n> I tried to reproduce the problem with git version 1.8.4.2 and\n> Subversion version 1.8.4 (r1534716) with a fresh and pristine\n> subversion repo and a git-svn clone of it: I didn't manage to\n> reproduce the rename issue. Then I switched subversion back to\n> 1.7.10, created both the repo and the git-svn clone, switched\n> againt to 1.8.4.2 and then got an error. Unfortunately I didn't\n> check if the subversion perlbindings were regenerated, so I'm\n> not exactly sure. I'll repeat the test again, as soon I've find\n> the time.\n>\n> It looks like a fresh git svn clone may fix the problem.\n>\n> Regards, Andy\n"},{"id":"230864","messageId":"CAM-uYMiLpsQdN41Gs8iJOT-v0qKgod2vEeoC3C+QJ5+wKiVK-Q@mail.gmail.com","threadId":"35337","inReplyTo":"52894951.7000303@futurelab.ch","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Benjamin Pabst","fromEmail":"benjamin.pabst85@gmail.com","sentAt":"2013-11-20T22:10:47Z","receivedAt":"2013-11-20T22:10:47Z","isPatch":false,"sender":{"key":"benjamin.pabst85@gmail.com","avatar":null},"body":"Hi,\n\nis it possible to debug git-svn or get a more verbose / debug output\nfrom it? I already tried with the \"GIT_TRACE\" variable, but it does\nnot include any further output on the svn methods.\n\nRegards, Benjamin\n\n2013/11/17 Andreas Stricker <astricker@futurelab.ch>:\n> Hi Jonathan\n>\n>> Can you give an exact sequence of steps (including \"Upgrade Subversion\n>> at this step\") to reproduce the problem?  That would help immensely\n>> --- if at all possible, I would very much like to keep existing\n>> git-svn repos working on upgrade.\n>\n> Of course. I've attached a text file with the commands required to\n> reproduce this error.\n>\n> From my experiments it looks like after the subversion is upgraded\n> to 1.8 the problem only occurs if \"git svn fetch\" fetches new changes\n> from the subversion repository. Without changes in upstream subversion\n> repository I couldn't reproduce the error. And a rename is required too.\n>\n> Hope this helps.\n>\n> Regards, Andy\n"},{"id":"232378","messageId":"1387919476-27921-1-git-send-email-rkagan@mail.ru","threadId":"35337","inReplyTo":"CAM-uYMiLpsQdN41Gs8iJOT-v0qKgod2vEeoC3C+QJ5+wKiVK-Q@mail.gmail.com","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-24T21:11:16Z","receivedAt":"2013-12-24T21:11:16Z","isPatch":false,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"Benjamin Pabst <benjamin.pabst85 <at> gmail.com> writes:\n> is it possible to debug git-svn or get a more verbose / debug output\n> from it? I already tried with the \"GIT_TRACE\" variable, but it does\n> not include any further output on the svn methods.\n\nI've hit this problem too, and tracked it down to what I think is a\nbug in svn.  It fails in libsvn_ra_serf/commit.c:close_file() on invalid\n->copy_path on the file context.\n\nAFAICT this is do to the ra_serf version of add_file() lacking\napr_pstrdup() on the \"copy_path\" argument passed to it; as a result it\ngets overwritten with garbage on further use:\n\nlibsvn_ra_serf/commit.c:\n...\n1852 static svn_error_t *\n1853 add_file(const char *path,\n1854          void *parent_baton,\n1855          const char *copy_path,\n1856          svn_revnum_t copy_revision,\n1857          apr_pool_t *file_pool,\n1858          void **file_baton)\n1859 {\n...\n1875   new_file->copy_path = copy_path;\n..\n\nYou can apply this workaround to get it to work:\n\n--- a/perl/Git/SVN/Editor.pm\n+++ b/perl/Git/SVN/Editor.pm\n@@ -304,8 +304,9 @@ sub C {\n \tmy ($self, $m, $deletions) = @_;\n \tmy ($dir, $file) = split_path($m->{file_b});\n \tmy $pbat = $self->ensure_path($dir, $deletions);\n+\tmy $upa = $self->url_path($m->{file_a});\n \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n-\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n+\t\t\t\t$upa, $self->{r});\n \tprint \"\\tC\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n \t$self->chg_file($fbat, $m);\n \t$self->close_file($fbat,undef,$self->{pool});\n@@ -323,8 +324,9 @@ sub R {\n \tmy ($self, $m, $deletions) = @_;\n \tmy ($dir, $file) = split_path($m->{file_b});\n \tmy $pbat = $self->ensure_path($dir, $deletions);\n+\tmy $upa = $self->url_path($m->{file_a});\n \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n-\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n+\t\t\t\t$upa, $self->{r});\n \tprint \"\\tR\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n \t$self->apply_autoprops($file, $fbat);\n \t$self->chg_file($fbat, $m);\n\n\nWhat it does is store the value to be passed to add_file() in a local\nvariable, and rely on perl to keep it alive through the end of function\nscope, beyond the call to close_file() where it's actually used.\n\nI'm going to submit a patch adding apr_pstrdup() to subversion folks.\nMeanwhile if people find the above workarond a sensible thing to do in\ngit, I can submit a properly formed patch here too.\n\nRoman.\n"},{"id":"232381","messageId":"CANiYKX40naaeUxaZEnYBcb7o5h7A9HPq5inuGjXn28R3NtzT1g@mail.gmail.com","threadId":"35337","inReplyTo":"1387919476-27921-1-git-send-email-rkagan@mail.ru","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-25T10:52:24Z","receivedAt":"2013-12-25T10:52:24Z","isPatch":false,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/25 Roman Kagan <rkagan@mail.ru>:\n> I've hit this problem too, and tracked it down to what I think is a\n> bug in svn.\n> [...]\n> I'm going to submit a patch adding apr_pstrdup() to subversion folks.\n\nhttp://thread.gmane.org/gmane.comp.version-control.subversion.devel/145186\n\nRoman.\n"},{"id":"232382","messageId":"CANiYKX60-ONS8Zc4O9WkieXaMWWqyqkq+ZdVy02EPUzx7XSEbQ@mail.gmail.com","threadId":"35337","inReplyTo":"CANiYKX40naaeUxaZEnYBcb7o5h7A9HPq5inuGjXn28R3NtzT1g@mail.gmail.com","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-25T13:13:18Z","receivedAt":"2013-12-25T13:13:18Z","isPatch":false,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/25 Roman Kagan <rkagan@mail.ru>:\n> 2013/12/25 Roman Kagan <rkagan@mail.ru>:\n>> I've hit this problem too, and tracked it down to what I think is a\n>> bug in svn.\n>> [...]\n>> I'm going to submit a patch adding apr_pstrdup() to subversion folks.\n>\n> http://thread.gmane.org/gmane.comp.version-control.subversion.devel/145186\n\nFWIW the patch was accepted and committed in subversion trunk.\n\nNevertheless I'll submit the workaround to git-svn, too, as it's\nharmless and may help some people (depending on the release cycles of\ngit and subversion).\n\nRoman.\n"},{"id":"232383","messageId":"87ha9wdh8g.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098","threadId":"35337","inReplyTo":"1387919476-27921-1-git-send-email-rkagan@mail.ru","subject":"Re: Fwd: Error with git-svn pushing a rename","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-12-25T16:31:59Z","receivedAt":"2013-12-25T16:31:59Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Roman Kagan <rkagan@mail.ru> writes:\n\n> --- a/perl/Git/SVN/Editor.pm\n> +++ b/perl/Git/SVN/Editor.pm\n> @@ -304,8 +304,9 @@ sub C {\n>  \tmy ($self, $m, $deletions) = @_;\n>  \tmy ($dir, $file) = split_path($m->{file_b});\n>  \tmy $pbat = $self->ensure_path($dir, $deletions);\n> +\tmy $upa = $self->url_path($m->{file_a});\n>  \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n> -\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n> +\t\t\t\t$upa, $self->{r});\n>  \tprint \"\\tC\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n>  \t$self->chg_file($fbat, $m);\n>  \t$self->close_file($fbat,undef,$self->{pool});\n> @@ -323,8 +324,9 @@ sub R {\n>  \tmy ($self, $m, $deletions) = @_;\n>  \tmy ($dir, $file) = split_path($m->{file_b});\n>  \tmy $pbat = $self->ensure_path($dir, $deletions);\n> +\tmy $upa = $self->url_path($m->{file_a});\n>  \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n> -\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n> +\t\t\t\t$upa, $self->{r});\n>  \tprint \"\\tR\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n>  \t$self->apply_autoprops($file, $fbat);\n>  \t$self->chg_file($fbat, $m);\n>\n>\n> What it does is store the value to be passed to add_file() in a local\n> variable, and rely on perl to keep it alive through the end of function\n> scope, beyond the call to close_file() where it's actually used.\n>\n> I'm going to submit a patch adding apr_pstrdup() to subversion folks.\n> Meanwhile if people find the above workarond a sensible thing to do in\n> git, I can submit a properly formed patch here too.\n\nIf you go this way, please add a comment that explains why we need the\nlocal variable.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"232397","messageId":"1388059524-4864-1-git-send-email-rkagan@mail.ru","threadId":"35337","inReplyTo":"87ha9wdh8g.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098","subject":"[PATCH] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-26T12:05:24Z","receivedAt":"2013-12-26T12:05:24Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"Subversion serf backend in versions 1.8.5 and below has a bug that the\nfunction creating the descriptor of a file change -- add_file() --\ndoesn't make a copy of its 3d argument when storing it on the returned\ndescriptor.  As a result, by the time this field is used (in\ntransactions of file copying or renaming) it may well be released.\n\nThis patch works around this bug, by storing the value to be passed as\nthe 3d argument to add_file() in a local variable with the same scope as\nthe file change descriptor, making sure their lifetime is the same.\n\nCc: Benjamin Pabst <benjamin.pabst85@gmail.com>\nCc: Eric Wong <normalperson@yhbt.net>\nSigned-off-by: Roman Kagan <rkagan@mail.ru>\n---\n perl/Git/SVN/Editor.pm | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm\nindex b3bcd47..ae399c3 100644\n--- a/perl/Git/SVN/Editor.pm\n+++ b/perl/Git/SVN/Editor.pm\n@@ -304,8 +304,12 @@ sub C {\n \tmy ($self, $m, $deletions) = @_;\n \tmy ($dir, $file) = split_path($m->{file_b});\n \tmy $pbat = $self->ensure_path($dir, $deletions);\n+\t# workaround for a bug in svn serf backend (v1.8.5 and below):\n+\t# store 3d argument to ->add_file() in a local variable, to make it\n+\t# have the same lifetime as $fbat\n+\tmy $upa = $self->url_path($m->{file_a});\n \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n-\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n+\t\t\t\t$upa, $self->{r});\n \tprint \"\\tC\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n \t$self->chg_file($fbat, $m);\n \t$self->close_file($fbat,undef,$self->{pool});\n@@ -323,8 +327,10 @@ sub R {\n \tmy ($self, $m, $deletions) = @_;\n \tmy ($dir, $file) = split_path($m->{file_b});\n \tmy $pbat = $self->ensure_path($dir, $deletions);\n+\t# workaround for a bug in svn serf backend, see comment in C() above\n+\tmy $upa = $self->url_path($m->{file_a});\n \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n-\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n+\t\t\t\t$upa, $self->{r});\n \tprint \"\\tR\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n \t$self->apply_autoprops($file, $fbat);\n \t$self->chg_file($fbat, $m);\n-- \n1.8.4.2\n"},{"id":"232417","messageId":"20131226202805.GV20443@google.com","threadId":"35337","inReplyTo":"1388059524-4864-1-git-send-email-rkagan@mail.ru","subject":"Re: [PATCH] git-svn: workaround for a bug in svn serf backend","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-12-26T20:28:05Z","receivedAt":"2013-12-26T20:28:05Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Roman Kagan wrote:\n\n> Subversion serf backend in versions 1.8.5 and below has a bug that the\n> function creating the descriptor of a file change -- add_file() --\n> doesn't make a copy of its 3d argument when storing it on the returned\n\n3d makes me think of 3-dimensional. ;-)  I think you mean third\n(or the abbreviation 3rd).\n\n> descriptor.  As a result, by the time this field is used (in\n> transactions of file copying or renaming) it may well be released.\n\nPlease describe the symptom so this patch is easy to find when other\npeople run into it.\n\nDo I remember correctly that \"... released and scribbled over with a\nnew value, causing such-and-such assertion to fire\" was what happened?\n\n> This patch works around this bug, by storing the value to be passed as\n> the 3d argument to add_file() in a local variable with the same scope as\n> the file change descriptor, making sure their lifetime is the same.\n\nCould this be reproduced with a test script to make sure we don't\nreintroduce the bug again later?  (It's okay if the test only fails on\nmachines with the problematic svn version.)\n\nModulo the confusing 3-dimensional arguments in comments, the code\nchange looks good.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"232425","messageId":"CANiYKX6VA2KvJ_YWYOegb6+VFg_unL96P9qUBthYPFuo9fhAMA@mail.gmail.com","threadId":"35337","inReplyTo":"20131226202805.GV20443@google.com","subject":"Re: [PATCH] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-27T06:09:30Z","receivedAt":"2013-12-27T06:09:30Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/27 Jonathan Nieder <jrnieder@gmail.com>:\n> Roman Kagan wrote:\n>\n>> Subversion serf backend in versions 1.8.5 and below has a bug that the\n>> function creating the descriptor of a file change -- add_file() --\n>> doesn't make a copy of its 3d argument when storing it on the returned\n>\n> 3d makes me think of 3-dimensional. ;-)  I think you mean third\n> (or the abbreviation 3rd).\n\nIndeed.\n\n>> descriptor.  As a result, by the time this field is used (in\n>> transactions of file copying or renaming) it may well be released.\n>\n> Please describe the symptom so this patch is easy to find when other\n> people run into it.\n\nOK\n\n> Do I remember correctly that \"... released and scribbled over with a\n> new value, causing such-and-such assertion to fire\" was what happened?\n\nExactly.\n\n>> This patch works around this bug, by storing the value to be passed as\n>> the 3d argument to add_file() in a local variable with the same scope as\n>> the file change descriptor, making sure their lifetime is the same.\n>\n> Could this be reproduced with a test script to make sure we don't\n> reintroduce the bug again later?  (It's okay if the test only fails on\n> machines with the problematic svn version.)\n\nThat would need a fairly fancy setup phase, as the bug triggers only\non http(s)-accessed svn repositories.  I'll take a look if there's\nsomething already available in the existing test scripts; writing one\nfrom scratch for this specific case is IMO beyond the reasonable\neffort.\n\n> Modulo the confusing 3-dimensional arguments in comments, the code\n> change looks good.\n\nThanks, I'll adjust the wording and resubmit.\n\nRoman.\n"},{"id":"232426","messageId":"CANiYKX4qGn0ZCVWTwWdrMfV_95mCePdd=q_BLJ6KH=MYOmqWbw@mail.gmail.com","threadId":"35337","inReplyTo":"CANiYKX6VA2KvJ_YWYOegb6+VFg_unL96P9qUBthYPFuo9fhAMA@mail.gmail.com","subject":"Re: [PATCH] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-27T07:52:50Z","receivedAt":"2013-12-27T07:52:50Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/27 Roman Kagan <rkagan@mail.ru>:\n> 2013/12/27 Jonathan Nieder <jrnieder@gmail.com>:\n>> Could this be reproduced with a test script to make sure we don't\n>> reintroduce the bug again later?  (It's okay if the test only fails on\n>> machines with the problematic svn version.)\n>\n> That would need a fairly fancy setup phase, as the bug triggers only\n> on http(s)-accessed svn repositories.  I'll take a look if there's\n> something already available in the existing test scripts\n\nTurns out the stuff is all there, and the tests doing file renames and\ndcomit-ting them do exist (t9115-git-svn-dcommit-funky-renames.sh for\none).\n\nHowever, the httpd setup is seriously broken; I haven't managed to get\nit to run on my Fedora 20 with apache 2.4.6.  Apparently git-svn tests\n(almost) never get executed against an http-based repository; even\nthose who don't set NO_SVN_TESTS get them run against file-based\nrepository and thus don't trigger the error.\n\nSomeone with better apache-foo needs to take a look into that.  Once\nthat is sorted out I believe the tests will start triggering the bug.\n\nMeanwhile I assume that the patch doesn't need to include an extra testcase.\n\nRoman.\n"},{"id":"232427","messageId":"1388131515-3015-1-git-send-email-rkagan@mail.ru","threadId":"35337","inReplyTo":"20131226202805.GV20443@google.com","subject":"[PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-27T08:05:15Z","receivedAt":"2013-12-27T08:05:15Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"Subversion serf backend in versions 1.8.5 and below has a bug that the\nfunction creating the descriptor of a file change -- add_file() --\ndoesn't make a copy of its third argument when storing it on the\nreturned descriptor.  As a result, by the time this field is used (in\ntransactions of file copying or renaming) it may well be released, and\nthe memory reused.\n\nOne of its possible manifestations is the svn assertion triggering on an\ninvalid path, with a message\n\nsvn_fspath__skip_ancestor: Assertion\n`svn_fspath__is_canonical(child_fspath)' failed.\n\nThis patch works around this bug, by storing the value to be passed as\nthe third argument to add_file() in a local variable with the same scope\nas the file change descriptor, making sure their lifetime is the same.\n\nCc: Benjamin Pabst <benjamin.pabst85@gmail.com>\nCc: Eric Wong <normalperson@yhbt.net>\nCc: Jonathan Nieder <jrnieder@gmail.com>\nSigned-off-by: Roman Kagan <rkagan@mail.ru>\n---\nchanges since v1:\n  - fix grammar in the patch and the log message\n  - refer to the triggered error message\n\n perl/Git/SVN/Editor.pm | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/perl/Git/SVN/Editor.pm b/perl/Git/SVN/Editor.pm\nindex b3bcd47..34e8af9 100644\n--- a/perl/Git/SVN/Editor.pm\n+++ b/perl/Git/SVN/Editor.pm\n@@ -304,8 +304,12 @@ sub C {\n \tmy ($self, $m, $deletions) = @_;\n \tmy ($dir, $file) = split_path($m->{file_b});\n \tmy $pbat = $self->ensure_path($dir, $deletions);\n+\t# workaround for a bug in svn serf backend (v1.8.5 and below):\n+\t# store third argument to ->add_file() in a local variable, to make it\n+\t# have the same lifetime as $fbat\n+\tmy $upa = $self->url_path($m->{file_a});\n \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n-\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n+\t\t\t\t$upa, $self->{r});\n \tprint \"\\tC\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n \t$self->chg_file($fbat, $m);\n \t$self->close_file($fbat,undef,$self->{pool});\n@@ -323,8 +327,10 @@ sub R {\n \tmy ($self, $m, $deletions) = @_;\n \tmy ($dir, $file) = split_path($m->{file_b});\n \tmy $pbat = $self->ensure_path($dir, $deletions);\n+\t# workaround for a bug in svn serf backend, see comment in C() above\n+\tmy $upa = $self->url_path($m->{file_a});\n \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n-\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n+\t\t\t\t$upa, $self->{r});\n \tprint \"\\tR\\t$m->{file_a} => $m->{file_b}\\n\" unless $::_q;\n \t$self->apply_autoprops($file, $fbat);\n \t$self->chg_file($fbat, $m);\n-- \n1.8.4.2\n"},{"id":"232448","messageId":"20131227200708.GD20443@google.com","threadId":"35337","inReplyTo":"1388131515-3015-1-git-send-email-rkagan@mail.ru","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-12-27T20:07:08Z","receivedAt":"2013-12-27T20:07:08Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Roman Kagan wrote:\n\n> Subversion serf backend in versions 1.8.5 and below has a bug that the\n> function creating the descriptor of a file change -- add_file() --\n> doesn't make a copy of its third argument when storing it on the\n> returned descriptor.  As a result, by the time this field is used (in\n> transactions of file copying or renaming) it may well be released, and\n> the memory reused.\n>\n> One of its possible manifestations is the svn assertion triggering on an\n> invalid path, with a message\n>\n> svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed.\n[...]\n\nMakes sense.  Perhaps also worth mentioning that this is fixed by\nr1553376, but no need to reroll just for that.\n\n> Cc: Benjamin Pabst <benjamin.pabst85@gmail.com>\n> Cc: Eric Wong <normalperson@yhbt.net>\n> Cc: Jonathan Nieder <jrnieder@gmail.com>\n\nNo need for these lines --- the mail header already keeps track of who\nis being cc-ed.\n\n> Signed-off-by: Roman Kagan <rkagan@mail.ru>\n\nReviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nThanks.\n"},{"id":"232449","messageId":"20131227203443.GA9189@dcvr.yhbt.net","threadId":"35337","inReplyTo":"20131227200708.GD20443@google.com","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2013-12-27T20:34:43Z","receivedAt":"2013-12-27T20:34:43Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Roman Kagan wrote:\n> \n> > Subversion serf backend in versions 1.8.5 and below has a bug that the\n> > function creating the descriptor of a file change -- add_file() --\n> > doesn't make a copy of its third argument when storing it on the\n> > returned descriptor.  As a result, by the time this field is used (in\n> > transactions of file copying or renaming) it may well be released, and\n> > the memory reused.\n> >\n> > One of its possible manifestations is the svn assertion triggering on an\n> > invalid path, with a message\n> >\n> > svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed.\n> [...]\n> \n> Makes sense.  Perhaps also worth mentioning that this is fixed by\n> r1553376, but no need to reroll just for that.\n\nThanks all, I noted this in an addendum to the commit:\n\n    Subversion serf backend in versions 1.8.5 and below has a bug(*) that the\n\n    ...\n\n    * [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder]\n\n> > Cc: Benjamin Pabst <benjamin.pabst85@gmail.com>\n> > Cc: Eric Wong <normalperson@yhbt.net>\n> > Cc: Jonathan Nieder <jrnieder@gmail.com>\n> \n> No need for these lines --- the mail header already keeps track of who\n> is being cc-ed.\n\nI don't mind seeing it in history.  At least I've gotten accustomed to\nit from the Linux kernel and tracking patch flow between dev -> stable\ntrees.\n\n> > Signed-off-by: Roman Kagan <rkagan@mail.ru>\n> \n> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n\nSigned-off-by: Eric Wong <normalperson@yhbt.net>\n\n\nThe following changes since commit 7794a680e63a2a11b73cb1194653662f2769a792:\n\n  Sync with 1.8.5.2 (2013-12-17 14:12:17 -0800)\n\nare available in the git repository at:\n\n\n  git://git.bogomips.org/git-svn.git master\n\nfor you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace:\n\n  git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +0000)\n\n----------------------------------------------------------------\nRoman Kagan (1):\n      git-svn: workaround for a bug in svn serf backend\n\n perl/Git/SVN/Editor.pm | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n"},{"id":"232458","messageId":"7veh4yj5mm.fsf@alter.siamese.dyndns.org","threadId":"35337","inReplyTo":"20131227203443.GA9189@dcvr.yhbt.net","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-27T22:22:57Z","receivedAt":"2013-12-27T22:22:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Jonathan Nieder <jrnieder@gmail.com> wrote:\n>> Roman Kagan wrote:\n>> \n>> > Subversion serf backend in versions 1.8.5 and below has a bug that the\n>> > function creating the descriptor of a file change -- add_file() --\n>> > doesn't make a copy of its third argument when storing it on the\n>> > returned descriptor.  As a result, by the time this field is used (in\n>> > transactions of file copying or renaming) it may well be released, and\n>> > the memory reused.\n>> >\n>> > One of its possible manifestations is the svn assertion triggering on an\n>> > invalid path, with a message\n>> >\n>> > svn_fspath__skip_ancestor: Assertion `svn_fspath__is_canonical(child_fspath)' failed.\n>> [...]\n>> \n>> Makes sense.  Perhaps also worth mentioning that this is fixed by\n>> r1553376, but no need to reroll just for that.\n>\n> Thanks all, I noted this in an addendum to the commit:\n>\n>     Subversion serf backend in versions 1.8.5 and below has a bug(*) that the\n>\n>     ...\n>\n>     * [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder]\n>\n>> > Cc: Benjamin Pabst <benjamin.pabst85@gmail.com>\n>> > Cc: Eric Wong <normalperson@yhbt.net>\n>> > Cc: Jonathan Nieder <jrnieder@gmail.com>\n>> \n>> No need for these lines --- the mail header already keeps track of who\n>> is being cc-ed.\n>\n> I don't mind seeing it in history.  At least I've gotten accustomed to\n> it from the Linux kernel and tracking patch flow between dev -> stable\n> trees.\n>\n>> > Signed-off-by: Roman Kagan <rkagan@mail.ru>\n>> \n>> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>\n>\n> Signed-off-by: Eric Wong <normalperson@yhbt.net>\n>\n>\n> The following changes since commit 7794a680e63a2a11b73cb1194653662f2769a792:\n>\n>   Sync with 1.8.5.2 (2013-12-17 14:12:17 -0800)\n>\n> are available in the git repository at:\n>\n>\n>   git://git.bogomips.org/git-svn.git master\n>\n> for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace:\n>\n>   git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +0000)\n>\n> ----------------------------------------------------------------\n> Roman Kagan (1):\n>       git-svn: workaround for a bug in svn serf backend\n>\n>  perl/Git/SVN/Editor.pm | 10 ++++++++--\n>  1 file changed, 8 insertions(+), 2 deletions(-)\n\nThanks. I almost missed this pull-request, though.\n\nWill pull.\n"},{"id":"232471","messageId":"CANiYKX4fjYYRneqPxFDmpPg7e5ge9-hNktBvXVLQ=JxtM56tAQ@mail.gmail.com","threadId":"35337","inReplyTo":"7veh4yj5mm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-28T09:58:22Z","receivedAt":"2013-12-28T09:58:22Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/28 Junio C Hamano <gitster@pobox.com>:\n> Eric Wong <normalperson@yhbt.net> writes:\n>>   git://git.bogomips.org/git-svn.git master\n>>\n>> for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace:\n>>\n>>   git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +0000)\n>>\n>> ----------------------------------------------------------------\n>> Roman Kagan (1):\n>>       git-svn: workaround for a bug in svn serf backend\n>>\n>>  perl/Git/SVN/Editor.pm | 10 ++++++++--\n>>  1 file changed, 8 insertions(+), 2 deletions(-)\n>\n> Thanks. I almost missed this pull-request, though.\n>\n> Will pull.\n\nThanks!\n\nI'd like to note that it's IMO worth including in the 'maint' branch\nas it's a crasher.  Especially so since the real fix has been merged\nin the subversion upstream and nominated for 1.8 branch, so the\nworkaround may soon lose its relevance.\n\nRoman.\n"},{"id":"232505","messageId":"87lhz2o7ht.fsf@thomasrast.ch","threadId":"35337","inReplyTo":"1388059524-4864-1-git-send-email-rkagan@mail.ru","subject":"Re: [PATCH] git-svn: workaround for a bug in svn serf backend","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-12-30T12:20:30Z","receivedAt":"2013-12-30T12:20:30Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Roman Kagan <rkagan@mail.ru> writes:\n\n> +\t# workaround for a bug in svn serf backend (v1.8.5 and below):\n> +\t# store 3d argument to ->add_file() in a local variable, to make it\n> +\t# have the same lifetime as $fbat\n> +\tmy $upa = $self->url_path($m->{file_a});\n>  \tmy $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n> -\t\t\t\t$self->url_path($m->{file_a}), $self->{r});\n> +\t\t\t\t$upa, $self->{r});\n\nHmm, now that you put it that way, I wonder if the patch is correct.\n\nLet me first rephrase the problem to verify that I understand the issue:\n\n  $fbat keeps a pointer to the $upa string, without maintaining a\n  reference to it.  When $fbat is destroyed, it needs this string, so we\n  must ensure that the lifetime of $upa is at least as long as that of\n  $fbat.\n\nHowever, does Perl make any guarantees as to the order in which local\nvariables are unreferenced and then destroyed?  I can't find any such\nguarantee.\n\nIn the absence of such, wouldn't we have to keep $upa in an outer,\nseparate scope to ensure that $fbat is destroyed first?\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"232511","messageId":"CANiYKX5Nd8YTsAKshma_-Ezqzw1tkC_-UJas0_oDxUZbcfaAAA@mail.gmail.com","threadId":"35337","inReplyTo":"87lhz2o7ht.fsf@thomasrast.ch","subject":"Re: [PATCH] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-30T16:01:10Z","receivedAt":"2013-12-30T16:01:10Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/30 Thomas Rast <tr@thomasrast.ch>:\n> Roman Kagan <rkagan@mail.ru> writes:\n>\n>> +     # workaround for a bug in svn serf backend (v1.8.5 and below):\n>> +     # store 3d argument to ->add_file() in a local variable, to make it\n>> +     # have the same lifetime as $fbat\n>> +     my $upa = $self->url_path($m->{file_a});\n>>       my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,\n>> -                             $self->url_path($m->{file_a}), $self->{r});\n>> +                             $upa, $self->{r});\n>\n> Hmm, now that you put it that way, I wonder if the patch is correct.\n>\n> Let me first rephrase the problem to verify that I understand the issue:\n>\n>   $fbat keeps a pointer to the $upa string, without maintaining a\n>   reference to it.  When $fbat is destroyed, it needs this string, so we\n>   must ensure that the lifetime of $upa is at least as long as that of\n>   $fbat.\n\nNo.  The string is needed in subversion's close_file(), so we want to\nkeep it alive until close_file() returns. Surviving till the end of\nthe current function scope is sufficient for that.\n\n> However, does Perl make any guarantees as to the order in which local\n> variables are unreferenced and then destroyed?\n\nWe don't care about the order they are destroyed WRT each other.\n\nRoman.\n"},{"id":"232522","messageId":"xmqq4n5qrume.fsf@gitster.dls.corp.google.com","threadId":"35337","inReplyTo":"CANiYKX4fjYYRneqPxFDmpPg7e5ge9-hNktBvXVLQ=JxtM56tAQ@mail.gmail.com","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-30T19:44:57Z","receivedAt":"2013-12-30T19:44:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Roman Kagan <rkagan@mail.ru> writes:\n\n> 2013/12/28 Junio C Hamano <gitster@pobox.com>:\n>> Eric Wong <normalperson@yhbt.net> writes:\n>>>   git://git.bogomips.org/git-svn.git master\n>>>\n>>> for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace:\n>>>\n>>>   git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +0000)\n>>>\n>>> ----------------------------------------------------------------\n>>> Roman Kagan (1):\n>>>       git-svn: workaround for a bug in svn serf backend\n>>>\n>>>  perl/Git/SVN/Editor.pm | 10 ++++++++--\n>>>  1 file changed, 8 insertions(+), 2 deletions(-)\n>>\n>> Thanks. I almost missed this pull-request, though.\n>>\n>> Will pull.\n>\n> Thanks!\n\nThat's redundant; the project should thank you for contributing, not\nthe other way around.\n\n> I'd like to note that it's IMO worth including in the 'maint' branch\n> as it's a crasher.  Especially so since the real fix has been merged\n> in the subversion upstream and nominated for 1.8 branch, so the\n> workaround may soon lose its relevance.\n\nI do not quite get this part, though.\n\nIf they refused to fix it for real, it would make it likely that\nthis workaround will stay relevant for a long time, in which case it\nwould be worth cherry-picking to an older maintenance track.  But if\nthis workaround is expected to lose its relevance shortly, I see it\nas one less reason to cherry-pick it to an older maintenance track.\n\nConfused...\n"},{"id":"232537","messageId":"CANiYKX5aUYWV2Kt_yMmAxeC07SuNcs-tJEe8e2SY4p1NHBPKUA@mail.gmail.com","threadId":"35337","inReplyTo":"xmqq4n5qrume.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2013-12-31T07:20:28Z","receivedAt":"2013-12-31T07:20:28Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/30 Junio C Hamano <gitster@pobox.com>:\n> Roman Kagan <rkagan@mail.ru> writes:\n>> I'd like to note that it's IMO worth including in the 'maint' branch\n>> as it's a crasher.  Especially so since the real fix has been merged\n>> in the subversion upstream and nominated for 1.8 branch, so the\n>> workaround may soon lose its relevance.\n>\n> I do not quite get this part, though.\n>\n> If they refused to fix it for real, it would make it likely that\n> this workaround will stay relevant for a long time, in which case it\n> would be worth cherry-picking to an older maintenance track.  But if\n> this workaround is expected to lose its relevance shortly, I see it\n> as one less reason to cherry-pick it to an older maintenance track.\n>\n> Confused...\n\nI thought it was exactly the other way around.  By the time the next\nfeature release reaches users, chances are they'd already have\nsubversion with the fix.  OTOH the workaround would benefit those who\nget their maintenance release of git (e.g. through their Linux distro\nupdate) before they get their maintenance release of subversion.\n\nDocumentation/SubmittingPatches also suggests to submit bugfixes\nagainst 'maint'.\n\nBut I might have got it wrong...\n\nRoman.\n"},{"id":"232725","messageId":"52CAD0E7.2050606@futurelab.ch","threadId":"35337","inReplyTo":"CANiYKX4fjYYRneqPxFDmpPg7e5ge9-hNktBvXVLQ=JxtM56tAQ@mail.gmail.com","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Andreas Stricker","fromEmail":"astricker@futurelab.ch","sentAt":"2014-01-06T15:51:03Z","receivedAt":"2014-01-06T15:51:03Z","isPatch":true,"sender":{"key":"astricker@futurelab.ch","avatar":"https://gravatar.com/avatar/007ac93f9abc20ee78c5169783fcf3f065d470d6b53d47050e30cf7ebad5025b?d=mp&s=160"},"body":"Hi Roman\n\n>>>   git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +0000)\n> Thanks!\n\nWell thanks to you for finding and fixing this bug that really annoyed\nme just before Christmas again. Your bug analysis proved my observation\nthat even a fresh checkout (as I suggested in my last message) didn't\nfix this issue.\n\nAnd thanks to the reviewers too. Awesome!\n\n~Andy\n"},{"id":"233285","messageId":"CANiYKX4VhxZsuwKMfaMToner-+ipYmsFy_T6Bgxwj_a950PA3A@mail.gmail.com","threadId":"35337","inReplyTo":"CANiYKX5aUYWV2Kt_yMmAxeC07SuNcs-tJEe8e2SY4p1NHBPKUA@mail.gmail.com","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Roman Kagan","fromEmail":"rkagan@mail.ru","sentAt":"2014-01-17T11:32:01Z","receivedAt":"2014-01-17T11:32:01Z","isPatch":true,"sender":{"key":"rkagan@mail.ru","avatar":"https://avatars.githubusercontent.com/u/10214432?v=4"},"body":"2013/12/31 Roman Kagan <rkagan@mail.ru>:\n> 2013/12/30 Junio C Hamano <gitster@pobox.com>:\n>> Roman Kagan <rkagan@mail.ru> writes:\n>>> I'd like to note that it's IMO worth including in the 'maint' branch\n>>> as it's a crasher.  Especially so since the real fix has been merged\n>>> in the subversion upstream and nominated for 1.8 branch, so the\n>>> workaround may soon lose its relevance.\n>>\n>> I do not quite get this part, though.\n>>\n>> If they refused to fix it for real, it would make it likely that\n>> this workaround will stay relevant for a long time, in which case it\n>> would be worth cherry-picking to an older maintenance track.  But if\n>> this workaround is expected to lose its relevance shortly, I see it\n>> as one less reason to cherry-pick it to an older maintenance track.\n>>\n>> Confused...\n>\n> I thought it was exactly the other way around.  By the time the next\n> feature release reaches users, chances are they'd already have\n> subversion with the fix.  OTOH the workaround would benefit those who\n> get their maintenance release of git (e.g. through their Linux distro\n> update) before they get their maintenance release of subversion.\n\nSo this actually happened: 1.8.5.3 is out, and some distributions are\nshipping it (Arch, Debian), but the workaround didn't make it there.\n\nCould you please consider including it in 'maint', so that 1.8.5.4\nbrings them a working combination of git and subversion?\n\nRoman.\n"},{"id":"233305","messageId":"xmqqr486wgyk.fsf@gitster.dls.corp.google.com","threadId":"35337","inReplyTo":"CANiYKX4VhxZsuwKMfaMToner-+ipYmsFy_T6Bgxwj_a950PA3A@mail.gmail.com","subject":"Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-17T19:23:15Z","receivedAt":"2014-01-17T19:23:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Roman Kagan <rkagan@mail.ru> writes:\n\n> 2013/12/31 Roman Kagan <rkagan@mail.ru>:\n>> 2013/12/30 Junio C Hamano <gitster@pobox.com>:\n>>> Roman Kagan <rkagan@mail.ru> writes:\n>>>> I'd like to note that it's IMO worth including in the 'maint' branch\n>>>> as it's a crasher.  Especially so since the real fix has been merged\n>>>> in the subversion upstream and nominated for 1.8 branch, so the\n>>>> workaround may soon lose its relevance.\n>>>\n>>> I do not quite get this part, though.\n>>>\n>>> If they refused to fix it for real, it would make it likely that\n>>> this workaround will stay relevant for a long time, in which case it\n>>> would be worth cherry-picking to an older maintenance track.  But if\n>>> this workaround is expected to lose its relevance shortly, I see it\n>>> as one less reason to cherry-pick it to an older maintenance track.\n>>>\n>>> Confused...\n>>\n>> I thought it was exactly the other way around.  By the time the next\n>> feature release reaches users, chances are they'd already have\n>> subversion with the fix.  OTOH the workaround would benefit those who\n>> get their maintenance release of git (e.g. through their Linux distro\n>> update) before they get their maintenance release of subversion.\n>\n> So this actually happened: 1.8.5.3 is out, and some distributions are\n> shipping it (Arch, Debian), but the workaround didn't make it there.\n\nThe way I read your message was that the fix on the subversion side\nis already there and this patch to work it around on our end is of\nno importance.\n\nBut actually you wanted to say quite the opposite.  They are slow\nand it is likely that we need to work their bug around for a while.\n\nIf so, then I think it might make sense to cherry-pick it to the\nmaint branch, even though we usually apply only fixes to our own\nbugs to the maintenance track.\n"}]}