* Re: [BUG] git-svn returning "Incomplete data: Delta source ended unexpectedly"
2010-07-14 22:16 ` Ævar Arnfjörð Bjarmason
@ 2010-08-25 18:31 ` Nicolas Noble
0 siblings, 0 replies; 4+ messages in thread
From: Nicolas Noble @ 2010-08-25 18:31 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Eric Wong, Git Mailing List
Hello,
I'm bumping this thread, as our git-svn mirror at work broke down
with the same exact problem. Now, rebuilding it wasn't exactly an
option, and I rather went the "restore backup" way, but my management
feels a bit nervous about git now since this issue hit us, and I
wasn't able to fix it in any way.
Basically, at our company, we're having subversion to track our
software codebase, but I'm trying hard to make people move to git. My
biggest (quite successful) attempt so far is to have a git-svn
"gateway" machine that people can clone in order to work on their own.
They don't have the right to push back, as it would obviously break
with the way git-svn works, but I take care of rebasing their commits
if they need to, in order to push them back onto the subversion. So we
have two sets of developers: one working with git, and one still with
svn. I'm having a crontab job that's using git-svn fetch every 2
minutes in order to get the gateway in sync at all times; the git-svn
rebase part doesn't really apply, as the point is to create local
branches from the subversion snapshots.
Now, yesterday, that exact issue described below hit us. But unlike
what's described below, both the git and svn history match perfectly.
Unfortunately, I can't upload the git repository anywhere, but as
far as I could see, there's indeed some blobs that don't match. But
for the life of me, I have absolutely no idea how to fix this without
going the backup way. I've tried to roll-back the remote branch to the
commit before, by hand-editing .git/refs/remotes/trunk,
.git/packed-refs, .git/info/refs and .git/svn/.metadata, running git
gc --prune in order to make sure I get rid of the corrupted blobs, and
re-running git svn fetch, but that didn't help. Probably because the
corruption happened even before, but then, I have no idea how to find
and fix this. I tried going back several days before, but no luck. And
the worst part is that I tried to skip over that commit, just to see,
using git-svn fetch --revision=xxxx and pointing at some revisions
after that, but ALL of the revisions I tried did the same thing, which
would tend to indicate that... everything is corrupted ? There's
something fundamentally wrong here, where I'm actually trusting
git-svn fetch to do the job properly and work at all time, yet it's
not.
Again, I can still restore backups, but my management would feel
much better if this issue was fixable instead. And the bad part is
that by backup, I mean I was running another git-svn mirror in
parallel on another machine, but for some reason, they diverged in
history. There's one commit message long time ago that didn't get
fetch from the subversion repository the same way, and from it, the
two history diverged. The delta of that commit itself is fine, but the
commit message got truncated. Which is of course going to have me
breaking any branches people created, and I'll have a very fun time
rebasing everything now :-)
I don't know exactly what kind of information I could provide in
order to troubleshoot, without disclosing our sourcecode, but if you'd
like to investigate this, I'd be happy to help and provide as much as
I can, as long as you describe what you'd need me to do.
Thanks!
-- Nicolas Noble
On Wed, Jul 14, 2010 at 3:16 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 21:09, Eric Wong <normalperson@yhbt.net> wrote:
>
>> Something went wrong with your mirror script (the way you're doing
>> externals is probably screwing it up, badly).
>>
>> Compare the "git svn log" output of your in-progress repository
>> with the "svn log http://josm.openstreetmap.de/svn/trunk"
>>
>> The revision numbers/commit messages don't sync up at all.
>
> Sorry for the false alarm, I didn't check that. Thanks for looking at
> it, and sorry for wasting your time.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 4+ messages in thread