Re: git-svn failure when symlink added in svn

Hi,

Seth Falcon <sethfalcon <at> gmail.com> writes:

Eric Wong <normalperson <at> yhbt.net> writes:

quoted

I can't reproduce it on Linux with ext3.  I translated your recipe into
a test script in the patch below.  Anybody familiar with OSX and/or HFS
know if there's a workaround or fix for this?

I've been investigating this problem too, as it keeps biting me when importing
our (OpenXPKIs) subversion tree using git-svn. I'd love to work with git and
am happy to help with debugging this further. Still, I am a pretty puzzled on why
this happens ...

And so then on Linux with -v I get (after snipping most of the
output):
   First, rewinding head to replay your work on top of it...
   symlink: 'foo.txt' => 'bar.txt'

On my OSX laptop I get:
   First, rewinding head to replay your work on top of it...
   symlink: 'foo.txt' => ''

Same here (this is a MacBook Pro, for what it's worth, BTW). As said, I've
investigated this a bit further. The empty filename in new seems to come from
trying to read the wrong SHA1 file. If one outputs ce->sha1 before
        void *new = read_sha1_file(ce->sha1, &type, size);
is called, one gets different output on Linux and Mac OS X.
For Seth's example, I get 5f34b0af07646aa529b5b005cde3a9559e606210 on Linux
and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 on Mac OS X ...

I've tried tracking down where this comes from. Here is what I've learned:
- read_blob_entry() is called from write_entry().
  SHA1 is already incorrect at that point in time.
- write_entry() is called from checkout_entry().
  SHA1 is already incorrect at that point in time.
- checkout_entry() is called from check_updates().
  SHA1 is already incorrect at that point in time.

Unluckily I could not figure out, where it is computed in the first place.
One idea was that maybe it was cached from the old file in the Mac OS X case
and recomputed on Linux or so? Or maybe it's not git's fault but git-svn
messes up (although I doubt it)?

I'll happy try out anything that has a slight chance of solving this issue
(workarounds greatly appreciated, too).

Best regards,
  Alex