git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUG] git-svn returning "Incomplete data: Delta source ended unexpectedly"

From
NNNicolas Noble <pixel.nobis@gmail.com>
Date
Aug 25, 2010, 18:31 UTC
Message-ID
<AANLkTi=QUiwUOAZtq_-c=D3S+AuFdZb9PEohVmYW+suW@mail.gmail.com>
In-Reply-To
<AANLkTil-QOQHNYIRvqDzfwicjo9SLXJPwgby-Z0b9rlT@mail.gmail.com>
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:

Show 17 quoted lines
> 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
>
Previous: Ævar Arnfjörð Bjarmason
Message 4 of 4 in “[BUG] git-svn returning "Incomplete data: Delta source ended unexpectedly"”
  1. Ævar Arnfjörð BjarmasonJul 14, 2010
  2. Eric WongJul 14, 2010
  3. Ævar Arnfjörð BjarmasonJul 14, 2010
  4. Nicolas NobleAug 25, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.