Re: git-svn failure when symlink added in svn

Seth Falcon [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

Seth Falcon [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:
...

quoted

Then I suspect the following could be less invasive and more
efficient fix for the problem.  I do not have an access to MacOS
box, and I do not have a working sync with any SVN repository,
so I cannot test it myself, though...

This also works as a fix for me on OS X and obviously is nicer than
resorting to temp files.  Again, with this patch against git master
the test case that Eric posted passes as does one of my own examples.

Well, I think the sysseek should be done only when we did read
'link ' from the beginning and not in other cases, so in that
sense my patch is very broken.  Probably the sysseek() needs to
be done inside the "if ($fb->mode_b} == 120000)" part, after it
checks for 'link '.

So I can confirm, unfortunately, that the suggested patch is indeed
very broken and have a couple of corrupt git-svn based repositories to
show for it -- in other words, I had the opportunity to learn a lesson
the hard way :-\

Eric: is there any way to undo some of the svn revs that have been
retrieved using git-svn fetch and then refetch them?  I naively tried
out Junio's fix and ran fetch on a few repositories.  The data
retrieved is bogus in a fun way that things work, but patches have
been repatched to remove 5 chars, e.g.:

    -factor <- function (x = character(), levels = sort(unique.default(x),
    +r <- function (x = character(), levels = sort(unique.default(x),

Assuming you're not using something crazy like noMetadata, you can just
use update-ref on the remote heads to the last known good revisions and
remove the associated .rev_db files.

Otherwise you'll have to delete entries from the .rev_db files, the
format is one line per-revision, the revision is the line number of the
file.

-- 
Eric Wong