{"thread":{"id":"7653","subject":"git-svn failure when symlink added in svn","startedAt":"2007-04-14T06:41:43Z","lastAt":"2007-05-01T20:53:04Z","messageCount":24,"participants":["Seth Falcon","Eric Wong","Alexander Klink","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39323","messageId":"m2647zh2zc.fsf@gmail.com","threadId":"7653","inReplyTo":null,"subject":"git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-14T06:41:43Z","receivedAt":"2007-04-14T06:41:43Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Hi,\n\nA few weeks ago I reported a symlink related error with git-svn and\nI've now had a chance to track down a few more details.  The trigger\nseems to be if a file is removed from svn and then later added as a\nsymlink.  The error I get is:\n\n  error: git-checkout-index: unable to create symlink foo.txt (Invalid argument)\n\nThis is from the call to symlink(new, path) in entry.c and it seems\nthat new is ''.\n\nHere is a recipe to reproduce:\n\n## First create an svn repository\n  svnadmin create SVN123-repos\n  svn co file:///Users/seth/temp/SVN123-repos SVN123\n  cd SVN123\n  echo 123 > foo.txt\n  svn add foo.txt \n  svn ci -m \"add a file\"\n\n## Now mirror using git-svn\n  cd ..\n  mkdir GIT123\n  cd GIT123/\n  git svn init file:///Users/seth/temp/SVN123-repos\n  git svn fetch\n\n## Next remove and add a file as a symlink\n  cd ..\n  cd SVN123\n  echo 123 > bar.txt\n  svn add bar.txt \n  svn ci -m\"add bar\"\n  svn rm foo.txt \n  svn ci -m \"remove foo\"\n  ln -s bar.txt foo.txt\n  svn add foo.txt \n  svn ci -m\"add foo as symlink\"\n\n## Finally, try to rebase\n  cd ../GIT123/\n  git svn rebase\n\ngit version 1.5.1.53.g77e6f\nsvn 1.4.0\n\n\n+ seth\n"},{"id":"39347","messageId":"20070414201003.GA28389@muzzle","threadId":"7653","inReplyTo":"m2647zh2zc.fsf@gmail.com","subject":"Re: git-svn failure when symlink added in svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-14T20:10:03Z","receivedAt":"2007-04-14T20:10:03Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Seth Falcon <sethfalcon@gmail.com> wrote:\n> A few weeks ago I reported a symlink related error with git-svn and\n> I've now had a chance to track down a few more details.  The trigger\n> seems to be if a file is removed from svn and then later added as a\n> symlink.  The error I get is:\n> \n>   error: git-checkout-index: unable to create symlink foo.txt (Invalid argument)\n> \n> This is from the call to symlink(new, path) in entry.c and it seems\n> that new is ''.\n\nI can't reproduce it on Linux with ext3.  I translated your recipe into\na test script in the patch below.  Anybody familiar with OSX and/or HFS\nknow if there's a workaround or fix for this?\n\nFrom: Eric Wong <normalperson@yhbt.net>\nDate: Sat, 14 Apr 2007 13:03:24 -0700\nSubject: [PATCH] git-svn: add test to handle conversion from file to symlink\n\nThis does not trigger any failures on my Linux machine with ext3,\nbut it may fail on OSX and/or HFS.\n\nThis test is based on a bug report by Seth Falcon:\n  http://permalink.gmane.org/gmane.comp.version-control.git/44445\n\nSigned-off-by: Eric Wong <normalperson@yhbt.net>\n---\n t/t9112-git-svn-file-to-symlink.sh |   36 ++++++++++++++++++++++++++++++++++++\n 1 files changed, 36 insertions(+), 0 deletions(-)\n create mode 100755 t/t9112-git-svn-file-to-symlink.sh\n\ndiff --git a/t/t9112-git-svn-file-to-symlink.sh b/t/t9112-git-svn-file-to-symlink.sh\nnew file mode 100755\nindex 0000000..f94310f\n--- /dev/null\n+++ b/t/t9112-git-svn-file-to-symlink.sh\n@@ -0,0 +1,36 @@\n+#!/bin/sh\n+# Copyright (c) 2007 Eric Wong\n+test_description='git-svn file to symlink'\n+. ./lib-git-svn.sh\n+\n+test_expect_success 'create file in svn repository' \"\n+\tsvn co '$svnrepo' svn &&\n+\tcd svn &&\n+\t\techo 123 > foo.txt &&\n+\t\tsvn add foo.txt &&\n+\t\tsvn commit -m 'add a file'\n+\t\tcd ..\n+\t\"\n+\n+test_expect_success 'clone with git-svn' \"pwd && git svn clone '$svnrepo' git\"\n+\n+test_expect_success 'remove and add file as symlink in svn' \"\n+\tcd svn &&\n+\t\techo 123 > bar.txt &&\n+\t\tsvn add bar.txt &&\n+\t\tsvn commit -m 'add bar' &&\n+\t\tsvn rm foo.txt &&\n+\t\tsvn commit -m 'remove foo' &&\n+\t\tln -s bar.txt foo.txt &&\n+\t\tsvn add foo.txt &&\n+\t\tsvn ci -m 'add foo as symlink'\n+\t\tcd ..\n+\t\"\n+\n+test_expect_success 'rebase in git-svn' \"\n+\tcd git &&\n+\t\tgit svn rebase\n+\t\tcd ..\n+\t\"\n+\n+test_done\n-- \nEric Wong\n"},{"id":"39444","messageId":"m2slb1c8ps.fsf@fhcrc.org","threadId":"7653","inReplyTo":"20070414201003.GA28389@muzzle","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-16T03:13:35Z","receivedAt":"2007-04-16T03:13:35Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n> I can't reproduce it on Linux with ext3.  I translated your recipe into\n> a test script in the patch below.  Anybody familiar with OSX and/or HFS\n> know if there's a workaround or fix for this?\n\nThanks for sending the test case.  It doesn't properly fail for me on\nOSX, but if I run it with -v then I do see the error (so it is failing\non OSX and, as you found, not on Linux).\n\nI added a silly print statement to see the symlink args:\n\ndiff --git a/entry.c b/entry.c\nindex d72f811..70f6402 100644\n--- a/entry.c\n+++ b/entry.c\n@@ -129,6 +129,7 @@ static int write_entry(struct cache_entry *ce, char *path, struct checkout *stat\n                                return error(\"git-checkout-index: unable to write file %s\",\n                                        path);\n                } else {\n+                        fprintf(stderr, \"symlink: '%s' => '%s'\\n\", path, new);\n                        wrote = symlink(new, path);\n                        free(new);\n                        if (wrote)\n\nAnd so then on Linux with -v I get (after snipping most of the\noutput):\n\n   * expecting success: \n           cd git &&\n                   git svn rebase\n                   cd ..\n   \n           A       bar.txt\n   r2 = 31e734669e3fe4dbbd375e5a9f5af828a5b7ba92 (git-svn)\n           D       foo.txt\n   r3 = bd3b318730e8efc77235976abb18d04bc927bf9e (git-svn)\n           A       foo.txt\n   r4 = 2376eedcfec1de7cbe69b2bbad1c5de231a0ed0d (git-svn)\n   First, rewinding head to replay your work on top of it...\n   symlink: 'foo.txt' => 'bar.txt'\n   HEAD is now at 2376eed... add foo as symlink\n   Fast-forwarded master to refs/remotes/git-svn.\n   *   ok 4: rebase in git-svn\n   \n   * passed all 4 test(s)\n\nOn my OSX laptop I get:\n\n   * expecting success: \n           cd git &&\n                   git svn rebase\n                   cd ..\n   \n           A       bar.txt\n   r2 = 4964f302b94ede0301b33faf5f4242c4bab3108b (git-svn)\n           D       foo.txt\n   r3 = 178a9ff3c7013d4ad8ec7defa93b91a1080c1e53 (git-svn)\n           A       foo.txt\n   r4 = 9f0bc38df8113fe1e11e47b708589d82bfa035a0 (git-svn)\n   First, rewinding head to replay your work on top of it...\n   symlink: 'foo.txt' => ''\n   error: git-checkout-index: unable to create symlink foo.txt (Invalid argument)\n   HEAD is now at 9f0bc38... add foo as symlink\n   Fast-forwarded master to refs/remotes/git-svn.\n   *   ok 4: rebase in git-svn\n   \n   * passed all 4 test(s)\n\nIf you're still with me, the curious part is what the symlink call is\ntrying to do.\n\n  Linux:    symlink: 'foo.txt' => 'bar.txt'\n    OSX:    symlink: 'foo.txt' => ''\n\nSo it looks like the problem is some sort of off-by-one that happens\nwell before the symlink call.  Perhaps this is enough for someone more\nknowledgable than me to have a clue where to look next?\n\n+ seth\n"},{"id":"40577","messageId":"loom.20070427T005115-751@post.gmane.org","threadId":"7653","inReplyTo":"m2slb1c8ps.fsf@fhcrc.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Alexander Klink","fromEmail":"ak-git@cynops.de","sentAt":"2007-04-26T23:07:09Z","receivedAt":"2007-04-26T23:07:09Z","isPatch":false,"sender":{"key":"ak-git@cynops.de","avatar":null},"body":"Hi,\n\nSeth Falcon <sethfalcon <at> gmail.com> writes:\n> Eric Wong <normalperson <at> yhbt.net> writes:\n> > I can't reproduce it on Linux with ext3.  I translated your recipe into\n> > a test script in the patch below.  Anybody familiar with OSX and/or HFS\n> > know if there's a workaround or fix for this?\n\nI've been investigating this problem too, as it keeps biting me when importing\nour (OpenXPKIs) subversion tree using git-svn. I'd love to work with git and\nam happy to help with debugging this further. Still, I am a pretty puzzled on why\nthis happens ...\n\n> And so then on Linux with -v I get (after snipping most of the\n> output):\n>    First, rewinding head to replay your work on top of it...\n>    symlink: 'foo.txt' => 'bar.txt'\n\n> On my OSX laptop I get:\n>    First, rewinding head to replay your work on top of it...\n>    symlink: 'foo.txt' => ''\n\nSame here (this is a MacBook Pro, for what it's worth, BTW). As said, I've\ninvestigated this a bit further. The empty filename in new seems to come from\ntrying to read the wrong SHA1 file. If one outputs ce->sha1 before\n        void *new = read_sha1_file(ce->sha1, &type, size);\nis called, one gets different output on Linux and Mac OS X.\nFor Seth's example, I get 5f34b0af07646aa529b5b005cde3a9559e606210 on Linux\nand e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 on Mac OS X ...\n\nI've tried tracking down where this comes from. Here is what I've learned:\n- read_blob_entry() is called from write_entry().\n  SHA1 is already incorrect at that point in time.\n- write_entry() is called from checkout_entry().\n  SHA1 is already incorrect at that point in time.\n- checkout_entry() is called from check_updates().\n  SHA1 is already incorrect at that point in time.\n\nUnluckily I could not figure out, where it is computed in the first place.\nOne idea was that maybe it was cached from the old file in the Mac OS X case\nand recomputed on Linux or so? Or maybe it's not git's fault but git-svn\nmesses up (although I doubt it)?\n\nI'll happy try out anything that has a slight chance of solving this issue\n(workarounds greatly appreciated, too).\n\nBest regards,\n  Alex\n"},{"id":"40616","messageId":"alpine.LFD.0.98.0704271100321.9964@woody.linux-foundation.org","threadId":"7653","inReplyTo":"loom.20070427T005115-751@post.gmane.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-27T18:03:50Z","receivedAt":"2007-04-27T18:03:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 26 Apr 2007, Alexander Klink wrote:\n> \n> Same here (this is a MacBook Pro, for what it's worth, BTW). As said, I've\n> investigated this a bit further. The empty filename in new seems to come from\n> trying to read the wrong SHA1 file. If one outputs ce->sha1 before\n>         void *new = read_sha1_file(ce->sha1, &type, size);\n> is called, one gets different output on Linux and Mac OS X.\n> For Seth's example, I get 5f34b0af07646aa529b5b005cde3a9559e606210 on Linux\n> and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 on Mac OS X ...\n\nWell, 5f34b0af0 is the \"bar.txt\" blob, while e69de29b is the empty blob\n\n(Eg do\n\n\t[torvalds@woody git]$ echo -en \"blob 7\\0bar.txt\" | sha1sum\n\t5f34b0af07646aa529b5b005cde3a9559e606210  -\n\n\t[torvalds@woody git]$ echo -en \"blob 0\\0\" | sha1sum\n\te69de29bb2d1d6434b8b29ae775ad8c2e48c5391  -\n\nto verify: git objects not only contain the data, but embed the object \ntype and size too).\n\nSo yeah, the printout matches the SHA1's, and the SHA1's are clearly not \ncorrupted: they are just a sign of the fact that the data that was fed to \nwhoever generated the SHA1's was simply different.\n\nBut why git-svn would act differently under OS X than under Linux I have \nno idea.\n\n\t\tLinus\n"},{"id":"40655","messageId":"loom.20070428T144858-521@post.gmane.org","threadId":"7653","inReplyTo":"alpine.LFD.0.98.0704271100321.9964@woody.linux-foundation.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Alexander Klink","fromEmail":"ak-git@cynops.de","sentAt":"2007-04-28T13:02:01Z","receivedAt":"2007-04-28T13:02:01Z","isPatch":false,"sender":{"key":"ak-git@cynops.de","avatar":null},"body":"Linus Torvalds <torvalds <at> linux-foundation.org> writes:\n\n> > trying to read the wrong SHA1 file. If one outputs ce->sha1 before\n> >         void *new = read_sha1_file(ce->sha1, &type, size);\n> > is called, one gets different output on Linux and Mac OS X.\n> > For Seth's example, I get 5f34b0af07646aa529b5b005cde3a9559e606210 on Linux\n> > and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 on Mac OS X ...\n> \n> Well, 5f34b0af0 is the \"bar.txt\" blob, while e69de29b is the empty blob\n> \n> So yeah, the printout matches the SHA1's, and the SHA1's are clearly not \n> corrupted: they are just a sign of the fact that the data that was fed to \n> whoever generated the SHA1's was simply different.\n\nThe SHA1 hashes are generated in the close_file() function in\ngit-svn.perl by forking git-hash-object -w --stdin and redirecting\nSTDIN to the passed filehandle. This is what goes wrong (for some\nperl-internal reason?) on Mac OS X. Here is a patch that works\naround that by putting the data to be hashed in a temporary file\nand calling git-hash-object with a filename.\n\nBest regards,\n    Alex\n\n>From 504892b882d05bdf1fbf2325e7544f52115555d1 Mon Sep 17 00:00:00 2001\nFrom: Alexander Klink <ak-git@cynops.de>\nDate: Sat, 28 Apr 2007 14:46:27 +0200\nSubject: [PATCH] Workaround for git-svn symlink problem on Mac OS X\n\ngit-svn had a problem with creating a symlink for a file which existed\nas a \"real\" file beforehand. See the report from Seth Falcon:\nhttp://permalink.gmane.org/gmane.comp.version-control.git/44445\nand the test patch by Eric Wong:\nhttp://permalink.gmane.org/gmane.comp.version-control.git/44469\n\nApparently, the reason for this is that in this case, perl on Mac OS X\ndoes not like the STDIN redirect in close_file() (which forks to\ngit-hash-object -w --stdin to create the SHA1 hash).\nThe workaround now creates a temporary file for the git-hash-object input\nusing File::Temp, calls git-hash-object -w with the filename and safely\nunlinks the file afterwards.\n---\n git-svn.perl |   18 +++++++++++-------\n 1 files changed, 11 insertions(+), 7 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 077d6b3..7af45aa 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2266,6 +2266,7 @@ use warnings;\n use Carp qw/croak/;\n use IO::File qw//;\n use Digest::MD5;\n+use File::Temp;\n \n # file baton members: path, mode_a, mode_b, pool, fh, blob, base\n sub new {\n@@ -2448,13 +2449,16 @@ sub close_file {\n \t\t\t$buf eq 'link ' or die \"$path has mode 120000\",\n \t\t\t                       \"but is not a link\\n\";\n \t\t}\n-\t\tdefined(my $pid = open my $out,'-|') or die \"Can't fork: $!\\n\";\n-\t\tif (!$pid) {\n-\t\t\topen STDIN, '<&', $fh or croak $!;\n-\t\t\texec qw/git-hash-object -w --stdin/ or croak $!;\n-\t\t}\n-\t\tchomp($hash = do { local $/; <$out> });\n-\t\tclose $out or croak $!;\n+\n+        # put the data for git-hash-object in a temporary file,\n+        # as redirecting STDIN does not always work for some reason on\n+        # Mac OS X\n+        my ($temp_fh, $temp_filename) = mkstemp(\"git-hash-input-XXXXXX\");\n+        print $temp_fh do { local $/; <$fh> };\n+\n+        chomp($hash = qx(git-hash-object -w $temp_filename));\n+        File::Temp::unlink0($temp_fh, $temp_filename)\n+            or die \"Error unlinking temporary file $temp_filename\";\n \t\tclose $fh or croak $!;\n \t\t$hash =~ /^[a-f\\d]{40}$/ or die \"not a sha1: $hash\\n\";\n \t\tclose $fb->{base} or croak $!;\n-- \n1.5.2.rc0.34.gda94-dirty\n"},{"id":"40658","messageId":"m2tzv0fnhc.fsf@ziti.fhcrc.org","threadId":"7653","inReplyTo":"loom.20070428T144858-521@post.gmane.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-28T16:54:55Z","receivedAt":"2007-04-28T16:54:55Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Hi Alex,\n\nAlexander Klink <ak-git@cynops.de> writes:\n> The SHA1 hashes are generated in the close_file() function in\n> git-svn.perl by forking git-hash-object -w --stdin and redirecting\n> STDIN to the passed filehandle. This is what goes wrong (for some\n> perl-internal reason?) on Mac OS X. Here is a patch that works\n> around that by putting the data to be hashed in a temporary file\n> and calling git-hash-object with a filename.\n\nI tested your patch and it works for me as well.  Eric's test case now\npasses and I was able to create a fresh clone of the problem svn\nrepository that contains the removal + symlink revisions [*1*].  I'm\nnot an OS X or Perl expert so it isn't obvious to me why the pipe\napproach isn't working.\n\nThanks much,\n\n+ seth\n\n[*1*] I can't seem to fix the git repository where this problem first\nappeared for me.  I tried creating a branch starting before the\nremoval and symlink creation and then running git-svn rebase, but that\ndidn't work -- maybe because git-svn already stored the commits in\ngarbled form.  Hence re-cloning was required.\n\nAlso: when I cloned the repository, I got a bus error when running git\nsvn fetch.  Rerunning git svn fetch completed.  Perhaps this is\nrelated to the other bug report that is in progress?  Sorry that I\ndon't have more details...\n"},{"id":"40665","messageId":"7virbgjthr.fsf@assigned-by-dhcp.cox.net","threadId":"7653","inReplyTo":"loom.20070428T144858-521@post.gmane.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-28T17:31:28Z","receivedAt":"2007-04-28T17:31:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Is it really the redirection that is the problem?\n\nThe process seeks $fh back to the beginning, reads 5 bytes from\nit (to ensure that is 'link '), and then forks to feed $fh to\ngit-hash-object.\n\nNow what do you really want to hash here?  I do not know what\nthis \"file that begins with 'link '\" magic is about, but I\nsuspect that the child may or may not start reading from byte\noffset 5 of that file, depending on how the low-level I/O is\ntied to Perl.\n\nHere is a little test script to imitate what the part in\nclose_file sub is doing.  What does it output on MacOS (or\nwhatever systems that are having the same problem)?\n\nOn a Linux box, it appears that it reads the remainder of the\nfile and the test script says \"child says: >>12345\", so I am\nassuming that is what close_file sub wants to do.  If my\nsuspicion is correct, you would get \"child says: >>link 12345\",\nin which case sysseek() commented out below would help,\nperhaps.\n\n-- >8 --\n#!/usr/bin/perl -w\n\nopen F, \">footest\";\nprint F \"link 12345\\n\";\nclose F;\n\nmy ($fh, $buf, $n, $pid, $out);\n\nopen $fh, \"<footest\";\nseek($fh, 0, 0);\n$n = read($fh, $buf, 5);\nprint \"read[$n]: $buf\\n\";\n\n$pid = open $out , '-|';\nif (!$pid) {\n\tmy $at = tell $fh;\n\tprint \"child: at $at\\n\";\n\n\t# We may want to do\n        #\n\t#\t sysseek($fh, 5, 0);\n        #\n        # here.\n\n\topen STDIN, '<&', $fh;\n\texec qw(sed -e s/^/>>/);\n}\nwhile (my $read = <$out>) {\n\tprint \"child says: $read\";\n}\nclose ($out);\nclose ($fh);\n"},{"id":"40668","messageId":"m2odl8fjv1.fsf@ziti.fhcrc.org","threadId":"7653","inReplyTo":"7virbgjthr.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-28T18:13:06Z","receivedAt":"2007-04-28T18:13:06Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Is it really the redirection that is the problem?\n>\n> The process seeks $fh back to the beginning, reads 5 bytes from\n> it (to ensure that is 'link '), and then forks to feed $fh to\n> git-hash-object.\n>\n> Now what do you really want to hash here?  I do not know what\n> this \"file that begins with 'link '\" magic is about, but I\n> suspect that the child may or may not start reading from byte\n> offset 5 of that file, depending on how the low-level I/O is\n> tied to Perl.\n>\n> Here is a little test script to imitate what the part in\n> close_file sub is doing.  What does it output on MacOS (or\n> whatever systems that are having the same problem)?\n>\n> On a Linux box, it appears that it reads the remainder of the\n> file and the test script says \"child says: >>12345\", so I am\n> assuming that is what close_file sub wants to do.  If my\n> suspicion is correct, you would get \"child says: >>link 12345\",\n> in which case sysseek() commented out below would help,\n> perhaps.\n\nOn OS X, I get:\n\n    ziti:~/temp seth$ ./perltest1.pl \n    read[5]: link \n    child says: child: at 5\n\nAnd uncommenting the sysseek call, I get:\n\n    ziti:~/temp seth$ ./perltest1.pl \n    read[5]: link \n    child says: child: at 5\n    child says: >>12345\n\n+ seth\n"},{"id":"40669","messageId":"7v7irwjql6.fsf@assigned-by-dhcp.cox.net","threadId":"7653","inReplyTo":"m2odl8fjv1.fsf@ziti.fhcrc.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-28T18:34:13Z","receivedAt":"2007-04-28T18:34:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth Falcon <sethfalcon@gmail.com> writes:\n\n> On OS X, I get:\n>\n>     ziti:~/temp seth$ ./perltest1.pl \n>     read[5]: link \n>     child says: child: at 5\n\nAh, so the previous read($fh, $buf, 5) lets stdio absorb the\nwhole (short) input, and the underlying seek pointer is not\nadjusted back across fork, and the child does not have anything\nto read.\n\n> And uncommenting the sysseek call, I get:\n>\n>     ziti:~/temp seth$ ./perltest1.pl \n>     read[5]: link \n>     child says: child: at 5\n>     child says: >>12345\n\nThen I suspect the following could be less invasive and more\nefficient fix for the problem.  I do not have an access to MacOS\nbox, and I do not have a working sync with any SVN repository,\nso I cannot test it myself, though...\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 7b5f8ab..e487da6 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2454,6 +2454,7 @@ sub close_file {\n \t\t}\n \t\tdefined(my $pid = open my $out,'-|') or die \"Can't fork: $!\\n\";\n \t\tif (!$pid) {\n+\t\t\tsysseek($fh, 5, 0);\n \t\t\topen STDIN, '<&', $fh or croak $!;\n \t\t\texec qw/git-hash-object -w --stdin/ or croak $!;\n \t\t}\n"},{"id":"40673","messageId":"m2k5vwfbf6.fsf@ziti.fhcrc.org","threadId":"7653","inReplyTo":"7v7irwjql6.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-28T21:15:25Z","receivedAt":"2007-04-28T21:15:25Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Seth Falcon <sethfalcon@gmail.com> writes:\n>\n>> On OS X, I get:\n>>\n>>     ziti:~/temp seth$ ./perltest1.pl \n>>     read[5]: link \n>>     child says: child: at 5\n>\n> Ah, so the previous read($fh, $buf, 5) lets stdio absorb the\n> whole (short) input, and the underlying seek pointer is not\n> adjusted back across fork, and the child does not have anything\n> to read.\n>\n>> And uncommenting the sysseek call, I get:\n>>\n>>     ziti:~/temp seth$ ./perltest1.pl \n>>     read[5]: link \n>>     child says: child: at 5\n>>     child says: >>12345\n>\n> Then I suspect the following could be less invasive and more\n> efficient fix for the problem.  I do not have an access to MacOS\n> box, and I do not have a working sync with any SVN repository,\n> so I cannot test it myself, though...\n\nThis also works as a fix for me on OS X and obviously is nicer than\nresorting to temp files.  Again, with this patch against git master\nthe test case that Eric posted passes as does one of my own examples.\n\n+ seth\n"},{"id":"40676","messageId":"7vwszwi0h2.fsf@assigned-by-dhcp.cox.net","threadId":"7653","inReplyTo":"m2k5vwfbf6.fsf@ziti.fhcrc.org","subject":"Re: git-svn failure when symlink added in svn","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-28T22:43:37Z","receivedAt":"2007-04-28T22:43:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seth Falcon <sethfalcon@gmail.com> writes:\n\n> Junio C Hamano <junkio@cox.net> writes:\n> ...\n>> Then I suspect the following could be less invasive and more\n>> efficient fix for the problem.  I do not have an access to MacOS\n>> box, and I do not have a working sync with any SVN repository,\n>> so I cannot test it myself, though...\n>\n> This also works as a fix for me on OS X and obviously is nicer than\n> resorting to temp files.  Again, with this patch against git master\n> the test case that Eric posted passes as does one of my own examples.\n\nWell, I think the sysseek should be done only when we did read\n'link ' from the beginning and not in other cases, so in that\nsense my patch is very broken.  Probably the sysseek() needs to\nbe done inside the \"if ($fb->mode_b} == 120000)\" part, after it\nchecks for 'link '.\n\nBy the way.\n\nI admit I have never given a serious look at the code of\ngit-svn.perl until now.\n\nIt has comparison with 120000 and 100644 all over with ==/!=.\nEven though these originally come from parse result of textual\noutput from ls-tree and diff-tree, and the code never treats\n$mode strings as octal integer, I would feel better if the\nliterals were quoted and comparison done with eq/ne.\n"},{"id":"40704","messageId":"20070429182649.GD12375@untitled","threadId":"7653","inReplyTo":"m2irbfqlze.fsf@ziti.local","subject":"Re: git-svn failure when symlink added in svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-29T18:26:49Z","receivedAt":"2007-04-29T18:26:49Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Seth Falcon <sethfalcon@gmail.com> wrote:\n> Junio C Hamano <junkio@cox.net> writes:\n> > Seth Falcon <sethfalcon@gmail.com> writes:\n> >> Junio C Hamano <junkio@cox.net> writes:\n> >> ...\n> >>> Then I suspect the following could be less invasive and more\n> >>> efficient fix for the problem.  I do not have an access to MacOS\n> >>> box, and I do not have a working sync with any SVN repository,\n> >>> so I cannot test it myself, though...\n> >>\n> >> This also works as a fix for me on OS X and obviously is nicer than\n> >> resorting to temp files.  Again, with this patch against git master\n> >> the test case that Eric posted passes as does one of my own examples.\n> >\n> > Well, I think the sysseek should be done only when we did read\n> > 'link ' from the beginning and not in other cases, so in that\n> > sense my patch is very broken.  Probably the sysseek() needs to\n> > be done inside the \"if ($fb->mode_b} == 120000)\" part, after it\n> > checks for 'link '.\n> \n> So I can confirm, unfortunately, that the suggested patch is indeed\n> very broken and have a couple of corrupt git-svn based repositories to\n> show for it -- in other words, I had the opportunity to learn a lesson\n> the hard way :-\\\n> \n> Eric: is there any way to undo some of the svn revs that have been\n> retrieved using git-svn fetch and then refetch them?  I naively tried\n> out Junio's fix and ran fetch on a few repositories.  The data\n> retrieved is bogus in a fun way that things work, but patches have\n> been repatched to remove 5 chars, e.g.:\n> \n>     -factor <- function (x = character(), levels = sort(unique.default(x),\n>     +r <- function (x = character(), levels = sort(unique.default(x),\n\nAssuming you're not using something crazy like noMetadata, you can just\nuse update-ref on the remote heads to the last known good revisions and\nremove the associated .rev_db files.\n\nOtherwise you'll have to delete entries from the .rev_db files, the\nformat is one line per-revision, the revision is the line number of the\nfile.\n\n-- \nEric Wong\n"},{"id":"40705","messageId":"20070429183136.GE12375@untitled","threadId":"7653","inReplyTo":"7vwszwi0h2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn failure when symlink added in svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-29T18:31:36Z","receivedAt":"2007-04-29T18:31:36Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Alexander: please don't drop me from the Cc next time, thanks.\n\nJunio C Hamano <junkio@cox.net> wrote:\n> Seth Falcon <sethfalcon@gmail.com> writes:\n> > Junio C Hamano <junkio@cox.net> writes:\n> > ...\n> >> Then I suspect the following could be less invasive and more\n> >> efficient fix for the problem.  I do not have an access to MacOS\n> >> box, and I do not have a working sync with any SVN repository,\n> >> so I cannot test it myself, though...\n> >\n> > This also works as a fix for me on OS X and obviously is nicer than\n> > resorting to temp files.  Again, with this patch against git master\n> > the test case that Eric posted passes as does one of my own examples.\n> \n> Well, I think the sysseek should be done only when we did read\n> 'link ' from the beginning and not in other cases, so in that\n> sense my patch is very broken.  Probably the sysseek() needs to\n> be done inside the \"if ($fb->mode_b} == 120000)\" part, after it\n> checks for 'link '.\n\nYes, don't add the new sysseek there.  All the reads and seeks in that\nblock of code should probably be sysreads and sysseeks instead.  Feel\nfree to patch and test this as I don't have time at the moment.\n\n> By the way.\n> \n> I admit I have never given a serious look at the code of\n> git-svn.perl until now.\n> \n> It has comparison with 120000 and 100644 all over with ==/!=.\n> Even though these originally come from parse result of textual\n> output from ls-tree and diff-tree, and the code never treats\n> $mode strings as octal integer, I would feel better if the\n> literals were quoted and comparison done with eq/ne.\n\nIt works either way as stringifying those would be unambiguous,\nalthough I understand strings can be considered better style...\nFeel free to change this.\n\n-- \nEric Wong\n"},{"id":"40716","messageId":"7vr6q2dhex.fsf@assigned-by-dhcp.cox.net","threadId":"7653","inReplyTo":"20070429183136.GE12375@untitled","subject":"Re: git-svn failure when symlink added in svn","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-29T21:01:10Z","receivedAt":"2007-04-29T21:01:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Alexander: please don't drop me from the Cc next time, thanks.\n>\n> Junio C Hamano <junkio@cox.net> wrote:\n>> Seth Falcon <sethfalcon@gmail.com> writes:\n>> > Junio C Hamano <junkio@cox.net> writes:\n>> > ...\n>> >> Then I suspect the following could be less invasive and more\n>> >> efficient fix for the problem.  I do not have an access to MacOS\n>> >> box, and I do not have a working sync with any SVN repository,\n>> >> so I cannot test it myself, though...\n>> ...\n>> \n>> Well, I think the sysseek should be done only when we did read\n>> 'link ' from the beginning and not in other cases, so in that\n>> sense my patch is very broken.  Probably the sysseek() needs to\n>> be done inside the \"if ($fb->mode_b} == 120000)\" part, after it\n>> checks for 'link '.\n>\n> Yes, don't add the new sysseek there.  All the reads and seeks in that\n> block of code should probably be sysreads and sysseeks instead.  Feel\n> free to patch and test this as I don't have time at the moment.\n\nOk.  As I do not have an access to a working sync with an SVN\nrepository nor a Mac OS box, I cannot test this, but something\nlike this should be applied to 'maint' before v1.5.1.3.  I've\nrun testsuite we have including t9XXX series, but that is the\nonly test I did.\n\nTesting, acks and feedback are very much appreciated.\n\n-- >8 --\nFix symlink handling in git-svn, related to PerlIO\n\nAfter reading the leading contents from a symlink data obtained\nfrom subversion, which we expect to begin with 'link ', the code\nforked to hash the remainder (which should match readlink()\nresult) using git-hash-objects, by redirecting its STDIN from\nthe filehandle we read that 'link ' from.  This was Ok with Perl\non modern Linux, but on Mac OS, the read in the parent process\nslurped more than we asked for in stdio buffer, and the child\ndid not correctly see the \"remainder\".\n\nThis attempts to fix the issue by using lower level sysseek and\nsysread instead of seek and read to bypass the stdio buffer.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n git-svn.perl |    6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 4be8576..cef6697 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2464,15 +2464,15 @@ sub close_file {\n \tmy $hash;\n \tmy $path = $self->git_path($fb->{path});\n \tif (my $fh = $fb->{fh}) {\n-\t\tseek($fh, 0, 0) or croak $!;\n+\t\tsysseek($fh, 0, 0) or croak $!;\n \t\tmy $md5 = Digest::MD5->new;\n \t\t$md5->addfile($fh);\n \t\tmy $got = $md5->hexdigest;\n \t\tdie \"Checksum mismatch: $path\\n\",\n \t\t    \"expected: $exp\\n    got: $got\\n\" if ($got ne $exp);\n-\t\tseek($fh, 0, 0) or croak $!;\n+\t\tsysseek($fh, 0, 0) or croak $!;\n \t\tif ($fb->{mode_b} == 120000) {\n-\t\t\tread($fh, my $buf, 5) == 5 or croak $!;\n+\t\t\tsysread($fh, my $buf, 5) == 5 or croak $!;\n \t\t\t$buf eq 'link ' or die \"$path has mode 120000\",\n \t\t\t                       \"but is not a link\\n\";\n \t\t}\n"},{"id":"40722","messageId":"20070429222136.GA1800@untitled","threadId":"7653","inReplyTo":"7vr6q2dhex.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn failure when symlink added in svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-29T22:21:36Z","receivedAt":"2007-04-29T22:21:36Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> diff --git a/git-svn.perl b/git-svn.perl\n> index 4be8576..cef6697 100755\n> --- a/git-svn.perl\n> +++ b/git-svn.perl\n> @@ -2464,15 +2464,15 @@ sub close_file {\n>  \tmy $hash;\n>  \tmy $path = $self->git_path($fb->{path});\n>  \tif (my $fh = $fb->{fh}) {\n> -\t\tseek($fh, 0, 0) or croak $!;\n> +\t\tsysseek($fh, 0, 0) or croak $!;\n>  \t\tmy $md5 = Digest::MD5->new;\n>  \t\t$md5->addfile($fh);\n\nWe may want to keep the plain seek() here and do both seek and sysseek,\nI'm not sure if $md5->addfile() uses read or sysread internally.\n\n-- \nEric Wong\n"},{"id":"40727","messageId":"20070430.d5c3a79fadd867d739e056ce9bc80eea@cynops.de","threadId":"7653","inReplyTo":"20070429222136.GA1800@untitled","subject":"Re: git-svn failure when symlink added in svn","fromName":"Alexander Klink","fromEmail":"ak-git@cynops.de","sentAt":"2007-04-30T00:24:00Z","receivedAt":"2007-04-30T00:24:00Z","isPatch":false,"sender":{"key":"ak-git@cynops.de","avatar":null},"body":"Hi,\n\nOn Sun, Apr 29, 2007 at 03:21:36PM -0700, Eric Wong wrote:\n> >  \tmy $path = $self->git_path($fb->{path});\n> >  \tif (my $fh = $fb->{fh}) {\n> > -\t\tseek($fh, 0, 0) or croak $!;\n> > +\t\tsysseek($fh, 0, 0) or croak $!;\n> >  \t\tmy $md5 = Digest::MD5->new;\n> >  \t\t$md5->addfile($fh);\n> \n> We may want to keep the plain seek() here and do both seek and sysseek,\n> I'm not sure if $md5->addfile() uses read or sysread internally.\nI've just had a quick look: it uses read.\nJunio: I'll test the patch tomorrow or the day after tommorow and\nlet you know whether it works for me. Thanks for the quick fix(es) ...\n\nBest regards,\n    Alex\n-- \nDipl.-Math. Alexander Klink | IT-Security Engineer |    a.klink@cynops.de\n mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de\n----------------------------+----------------------+---------------------\n      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:\n     Bad Homburg v. d. Höhe |                      |      Martin Bartosch\n"},{"id":"40730","messageId":"7vmz0qcuut.fsf@assigned-by-dhcp.cox.net","threadId":"7653","inReplyTo":"20070429222136.GA1800@untitled","subject":"Re: git-svn failure when symlink added in svn","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-30T05:08:26Z","receivedAt":"2007-04-30T05:08:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> diff --git a/git-svn.perl b/git-svn.perl\n>> index 4be8576..cef6697 100755\n>> --- a/git-svn.perl\n>> +++ b/git-svn.perl\n>> @@ -2464,15 +2464,15 @@ sub close_file {\n>>  \tmy $hash;\n>>  \tmy $path = $self->git_path($fb->{path});\n>>  \tif (my $fh = $fb->{fh}) {\n>> -\t\tseek($fh, 0, 0) or croak $!;\n>> +\t\tsysseek($fh, 0, 0) or croak $!;\n>>  \t\tmy $md5 = Digest::MD5->new;\n>>  \t\t$md5->addfile($fh);\n>\n> We may want to keep the plain seek() here and do both seek and sysseek,\n> I'm not sure if $md5->addfile() uses read or sysread internally.\n\nOk.  The seek before Digest::MD5 can stay as it has been that\nway for a long time without causing problems.  How about this as\nan replacement then?\n\n-- >8 --\n[PATCH] Fix symlink handling in git-svn, related to PerlIO\n\nAfter reading the leading contents from a symlink data obtained\nfrom subversion, which we expect to begin with 'link ', the code\nforked to hash the remainder (which should match readlink()\nresult) using git-hash-objects, by redirecting its STDIN from\nthe filehandle we read that 'link ' from.  This was Ok with Perl\non modern Linux, but on Mac OS, the read in the parent process\nslurped more than we asked for in stdio buffer, and the child\ndid not correctly see the \"remainder\".\n\nThis attempts to fix the issue by using lower level sysseek and\nsysread instead of seek and read to bypass the stdio buffer.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n git-svn.perl |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 4be8576..6f509f8 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2470,9 +2470,9 @@ sub close_file {\n \t\tmy $got = $md5->hexdigest;\n \t\tdie \"Checksum mismatch: $path\\n\",\n \t\t    \"expected: $exp\\n    got: $got\\n\" if ($got ne $exp);\n-\t\tseek($fh, 0, 0) or croak $!;\n+\t\tsysseek($fh, 0, 0) or croak $!;\n \t\tif ($fb->{mode_b} == 120000) {\n-\t\t\tread($fh, my $buf, 5) == 5 or croak $!;\n+\t\t\tsysread($fh, my $buf, 5) == 5 or croak $!;\n \t\t\t$buf eq 'link ' or die \"$path has mode 120000\",\n \t\t\t                       \"but is not a link\\n\";\n \t\t}\n-- \n1.5.2.rc0.781.g5868\n"},{"id":"40734","messageId":"20070430063133.GA14414@untitled","threadId":"7653","inReplyTo":"7vmz0qcuut.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn failure when symlink added in svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-30T06:31:33Z","receivedAt":"2007-04-30T06:31:33Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Eric Wong <normalperson@yhbt.net> writes:\n> \n> > Junio C Hamano <junkio@cox.net> wrote:\n> >> diff --git a/git-svn.perl b/git-svn.perl\n> >> index 4be8576..cef6697 100755\n> >> --- a/git-svn.perl\n> >> +++ b/git-svn.perl\n> >> @@ -2464,15 +2464,15 @@ sub close_file {\n> >>  \tmy $hash;\n> >>  \tmy $path = $self->git_path($fb->{path});\n> >>  \tif (my $fh = $fb->{fh}) {\n> >> -\t\tseek($fh, 0, 0) or croak $!;\n> >> +\t\tsysseek($fh, 0, 0) or croak $!;\n> >>  \t\tmy $md5 = Digest::MD5->new;\n> >>  \t\t$md5->addfile($fh);\n> >\n> > We may want to keep the plain seek() here and do both seek and sysseek,\n> > I'm not sure if $md5->addfile() uses read or sysread internally.\n> \n> Ok.  The seek before Digest::MD5 can stay as it has been that\n> way for a long time without causing problems.  How about this as\n> an replacement then?\n\nLooks good to me.  Seth?\n\nIf Seth is okay with it, then:\nAcked-by: Eric Wong <normalperson@yhbt.net>\n\n> -- >8 --\n> [PATCH] Fix symlink handling in git-svn, related to PerlIO\n> \n> After reading the leading contents from a symlink data obtained\n> from subversion, which we expect to begin with 'link ', the code\n> forked to hash the remainder (which should match readlink()\n> result) using git-hash-objects, by redirecting its STDIN from\n> the filehandle we read that 'link ' from.  This was Ok with Perl\n> on modern Linux, but on Mac OS, the read in the parent process\n> slurped more than we asked for in stdio buffer, and the child\n> did not correctly see the \"remainder\".\n> \n> This attempts to fix the issue by using lower level sysseek and\n> sysread instead of seek and read to bypass the stdio buffer.\n> \n> Signed-off-by: Junio C Hamano <junkio@cox.net>\n> ---\n>  git-svn.perl |    4 ++--\n>  1 files changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/git-svn.perl b/git-svn.perl\n> index 4be8576..6f509f8 100755\n> --- a/git-svn.perl\n> +++ b/git-svn.perl\n> @@ -2470,9 +2470,9 @@ sub close_file {\n>  \t\tmy $got = $md5->hexdigest;\n>  \t\tdie \"Checksum mismatch: $path\\n\",\n>  \t\t    \"expected: $exp\\n    got: $got\\n\" if ($got ne $exp);\n> -\t\tseek($fh, 0, 0) or croak $!;\n> +\t\tsysseek($fh, 0, 0) or croak $!;\n>  \t\tif ($fb->{mode_b} == 120000) {\n> -\t\t\tread($fh, my $buf, 5) == 5 or croak $!;\n> +\t\t\tsysread($fh, my $buf, 5) == 5 or croak $!;\n>  \t\t\t$buf eq 'link ' or die \"$path has mode 120000\",\n>  \t\t\t                       \"but is not a link\\n\";\n>  \t\t}\n> -- \n> 1.5.2.rc0.781.g5868\n\n-- \nEric Wong\n"},{"id":"40745","messageId":"m2abwqq6d9.fsf@ziti.local","threadId":"7653","inReplyTo":"20070430063133.GA14414@untitled","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-30T14:33:38Z","receivedAt":"2007-04-30T14:33:38Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> Eric Wong <normalperson@yhbt.net> writes:\n>> \n>> > Junio C Hamano <junkio@cox.net> wrote:\n>> >> diff --git a/git-svn.perl b/git-svn.perl\n>> >> index 4be8576..cef6697 100755\n>> >> --- a/git-svn.perl\n>> >> +++ b/git-svn.perl\n>> >> @@ -2464,15 +2464,15 @@ sub close_file {\n>> >>  \tmy $hash;\n>> >>  \tmy $path = $self->git_path($fb->{path});\n>> >>  \tif (my $fh = $fb->{fh}) {\n>> >> -\t\tseek($fh, 0, 0) or croak $!;\n>> >> +\t\tsysseek($fh, 0, 0) or croak $!;\n>> >>  \t\tmy $md5 = Digest::MD5->new;\n>> >>  \t\t$md5->addfile($fh);\n>> >\n>> > We may want to keep the plain seek() here and do both seek and sysseek,\n>> > I'm not sure if $md5->addfile() uses read or sysread internally.\n>> \n>> Ok.  The seek before Digest::MD5 can stay as it has been that\n>> way for a long time without causing problems.  How about this as\n>> an replacement then?\n>\n> Looks good to me.  Seth?\n\nThe test cases passes as does the small example I had come up with.  I\nalso tried doing a git svn clone on a small repos and checking that\nthe resulting HEAD was the same as a previously created one (it was).\n\n> If Seth is okay with it, then:\n> Acked-by: Eric Wong <normalperson@yhbt.net>\nAcked-by: Seth Falcon <sethfalcon@gmail.com>\n\n\n+ seth\n"},{"id":"40746","messageId":"m24pmxrkgt.fsf@ziti.local","threadId":"7653","inReplyTo":"20070429182649.GD12375@untitled","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-04-30T14:43:46Z","receivedAt":"2007-04-30T14:43:46Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Seth Falcon <sethfalcon@gmail.com> wrote:\n>> Eric: is there any way to undo some of the svn revs that have been\n>> retrieved using git-svn fetch and then refetch them? \n\n> Assuming you're not using something crazy like noMetadata, you can just\n> use update-ref on the remote heads to the last known good revisions and\n> remove the associated .rev_db files.\n>\n> Otherwise you'll have to delete entries from the .rev_db files, the\n> format is one line per-revision, the revision is the line number of the\n> file.\n\nHmm, not sure I understood.  Here's what I tried:\n\nI'm tracking two branches via git-svn.  For each, I used git log\nremotes/<branch> to find a revision that I expect to be ok and noted\nthe sha1.  Then I did: \n\n    git-update-ref remotes/git-svn a27b11c1\n\nand similar, but with different sha1 for the other branch.  Next I\nremoved the .rev_db* files (there was one for each svn branch) and\ntried doing git-svn fetch.  This seemed to rebuild the .rev_db, but\neventually I ended up with:\n\nDone rebuilding .git/svn/git-svn/.rev_db.00db46b3-68df-0310-9c12-caf00c1e9a41\n        M       src/<somepath>\n        M       src/<another>\nIncomplete data: Delta source ended unexpectedly at /Users/seth/scm/bin/git-svn line 2982\n\nAnd if I rerun git svn fetch, I get:\n\nIndex mismatch: 9c07a6009029e4a1d834ff126f705c4db3c4bce7 != 67dc53678f759c52a93a281f13fadb08799f86b2\nrereading 0f12c8c092600c8a3337ec35d153d3a76ce2329d\n        M       src/<somepath>\n        M       src/<another>\nIncomplete data: Delta source ended unexpectedly at /Users/seth/scm/bin/git-svn line 2982\n\n\n[where <somepath> and <another> are the same in both cases]\n\nDid I miss a step or misunderstand how to undo?  What's strange is\nthat if I do git show 0f12c8c, I see a patch that is looks like it came\nfrom a fetch using the my broken version of git-svn -- do I need to\nclear out objects before refetching?\n\nThanks,\n\n+ seth\n"},{"id":"40747","messageId":"20070430154359.GD1800@untitled","threadId":"7653","inReplyTo":"m24pmxrkgt.fsf@ziti.local","subject":"Re: git-svn failure when symlink added in svn","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-04-30T15:43:59Z","receivedAt":"2007-04-30T15:43:59Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Seth Falcon <sethfalcon@gmail.com> wrote:\n> Eric Wong <normalperson@yhbt.net> writes:\n> \n> > Seth Falcon <sethfalcon@gmail.com> wrote:\n> >> Eric: is there any way to undo some of the svn revs that have been\n> >> retrieved using git-svn fetch and then refetch them? \n> \n> > Assuming you're not using something crazy like noMetadata, you can just\n> > use update-ref on the remote heads to the last known good revisions and\n> > remove the associated .rev_db files.\n> >\n> > Otherwise you'll have to delete entries from the .rev_db files, the\n> > format is one line per-revision, the revision is the line number of the\n> > file.\n> \n> Hmm, not sure I understood.  Here's what I tried:\n> \n> I'm tracking two branches via git-svn.  For each, I used git log\n> remotes/<branch> to find a revision that I expect to be ok and noted\n> the sha1.  Then I did: \n> \n>     git-update-ref remotes/git-svn a27b11c1\n\nYou may need to specify \"refs/\": \"refs/remotes/git-svn\".\nIs there a .git/remotes/git-svn ref file now?\n\n> and similar, but with different sha1 for the other branch.  Next I\n> removed the .rev_db* files (there was one for each svn branch) and\n> tried doing git-svn fetch.  This seemed to rebuild the .rev_db, but\n> eventually I ended up with:\n> \n> Done rebuilding .git/svn/git-svn/.rev_db.00db46b3-68df-0310-9c12-caf00c1e9a41\n>         M       src/<somepath>\n>         M       src/<another>\n> Incomplete data: Delta source ended unexpectedly at /Users/seth/scm/bin/git-svn line 2982\n> \n> And if I rerun git svn fetch, I get:\n> \n> Index mismatch: 9c07a6009029e4a1d834ff126f705c4db3c4bce7 != 67dc53678f759c52a93a281f13fadb08799f86b2\n> rereading 0f12c8c092600c8a3337ec35d153d3a76ce2329d\n>         M       src/<somepath>\n>         M       src/<another>\n> Incomplete data: Delta source ended unexpectedly at /Users/seth/scm/bin/git-svn line 2982\n> \n> \n> [where <somepath> and <another> are the same in both cases]\n> \n> Did I miss a step or misunderstand how to undo?  What's strange is\n> that if I do git show 0f12c8c, I see a patch that is looks like it came\n> from a fetch using the my broken version of git-svn -- do I need to\n> clear out objects before refetching?\n\nI might have left some steps (I've been all over the place lately :/).\nYou probably need to do all that and also need to edit\n.git/svn/.metadata and set the {branches,tags}-maxRev fields to the last\nknown good revisions if you use globs.\n\nAlso you can try removing the index files inside .git/svn (but they\n*should* be auto-checked and rebuilt (as they were in the second\n\"git-svn fetch\" run you did...\n\n-- \nEric Wong\n"},{"id":"40840","messageId":"m2wszsigcd.fsf@ziti.local","threadId":"7653","inReplyTo":"20070430154359.GD1800@untitled","subject":"Re: git-svn failure when symlink added in svn","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2007-05-01T17:49:54Z","receivedAt":"2007-05-01T17:49:54Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Seth Falcon <sethfalcon@gmail.com> wrote:\n>> Eric Wong <normalperson@yhbt.net> writes:\n>> \n>> > Seth Falcon <sethfalcon@gmail.com> wrote:\n>> >> Eric: is there any way to undo some of the svn revs that have been\n>> >> retrieved using git-svn fetch and then refetch them? \n>> \n>> > Assuming you're not using something crazy like noMetadata, you can just\n>> > use update-ref on the remote heads to the last known good revisions and\n>> > remove the associated .rev_db files.\n>> >\n>> > Otherwise you'll have to delete entries from the .rev_db files, the\n>> > format is one line per-revision, the revision is the line number of the\n>> > file.\n>> \n>> Hmm, not sure I understood.  Here's what I tried:\n>> \n>> I'm tracking two branches via git-svn.  For each, I used git log\n>> remotes/<branch> to find a revision that I expect to be ok and noted\n>> the sha1.  Then I did: \n>> \n>>     git-update-ref remotes/git-svn a27b11c1\n>\n> You may need to specify \"refs/\": \"refs/remotes/git-svn\".\n> Is there a .git/remotes/git-svn ref file now?\n\nYes.  I removed those and redid the git-update-ref specifying\nrefs/remotes/git-svn and the branch I have.\n\n>> Did I miss a step or misunderstand how to undo?  What's strange is\n>> that if I do git show 0f12c8c, I see a patch that is looks like it came\n>> from a fetch using the my broken version of git-svn -- do I need to\n>> clear out objects before refetching?\n>\n> I might have left some steps (I've been all over the place lately :/).\n> You probably need to do all that and also need to edit\n> .git/svn/.metadata and set the {branches,tags}-maxRev fields to the last\n> known good revisions if you use globs.\n\nI ran git-gc --prune.  I also took a look at .git/svn/.metadata, but\nall I have there is:\n\n    ; This file is used internally by git-svn\n    ; You should not have to edit it\n    [svn-remote \"svn\"]\n            uuid = 00db46b3-68df-0310-9c12-caf00c1e9a41\n\nSo I left that alone.  I tried refetching and end up with the\nfollowing error after the rev dbs were rebuilt:\n\n    error: invalid object 67e31e0ada47e8e9d15547ff1a48298869b3907b\n    fatal: git-write-tree: error building trees\n    write-tree: command returned error: 128\n\nI found a backup of this repository and will use that.  Since I have a\nbackup, it isn't worth the effort.  I think the obvious lesson is to\nuse a copy of a repos when testing git-svn so you can throw it away if\nthings go awry.\n\n+ seth\n"},{"id":"40853","messageId":"20070501.8cc6c8feecd24d6cb7e7b7907dec9cb2@cynops.de","threadId":"7653","inReplyTo":"7vmz0qcuut.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn failure when symlink added in svn","fromName":"Alexander Klink","fromEmail":"ak-git@cynops.de","sentAt":"2007-05-01T20:53:04Z","receivedAt":"2007-05-01T20:53:04Z","isPatch":false,"sender":{"key":"ak-git@cynops.de","avatar":null},"body":"On Sun, Apr 29, 2007 at 10:08:26PM -0700, Junio C Hamano wrote:\n> -- >8 --\n> [PATCH] Fix symlink handling in git-svn, related to PerlIO\n> \n[...]\n> This attempts to fix the issue by using lower level sysseek and\n> sysread instead of seek and read to bypass the stdio buffer.\nWorks fine here, too. Thanks again for the quick response ...\n\nRegards,\n    Alex\n"}]}