Re: git-svn failure when symlink added in svn

From: Alexander Klink <ak-git@cynops.de>
Date: Apr 26, 2007, 23:07 UTC
Message-ID: <loom.20070427T005115-751@post.gmane.org>
In-Reply-To: <m2slb1c8ps.fsf@fhcrc.org>

Hi,

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

> Eric Wong <normalperson <at> yhbt.net> writes:
> > 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