Subvertpy fails with an assertion on hg+hgsubversion SVN repository cloning

Create issue
Issue #294 open
sergey created an issue

Hi, this is Mercurial 1.8.4 and Subversion server 1.6.15 on Linux. I filed 805784 ( on Subvertpy tracker but it seems like it's happening due to something hgsubversion does. Full stack trace is on Subvertpy tracker at the URL above. I'll get the exact hgsubversion version.

AssertionError("%d != %d" % (len(tview), tview_len)) in, line 57, in apply_txdelta_window

Comments (18)

  1. sergey reporter

    The same repository was converted successfully with standard-issue Subversion SWIG bindings (as suggested on subvertpy ticket).

  2. Dan Villiom Podlaski Christiansen

    Could you please do a 'hg svn verify' on the revision that fails? (From a SWIG conversion, of course.) As jelmer suggested in the launchpad bug, Subvertpy may be catching actual repository corruption.

  3. Yonggang Luo

    I think this kinds of mysterious issue just to be close, so we can focus on other meaningful issues. Except svn log attached, repository is better, or this can not be fixed.

  4. Yonggang Luo

    I think this kinds of mysterious issue just to be close, so we can focus on other meaningful issues. Except svn log attached, repository is better, or this can not be fixed.

  5. Bruno Franca dos Reis

    I don't know why my previous comment didn't appear. Maybe it is on a moderation queue.

    Just to let you know that I finally managed to make it work.

    What I did was: apt-get remove python-subvertpy, which actually replaced the package by python-subversion. Now it seems to work.

    I can't tell for sure, but apparently everything is slower now, but better slower than not working.

    [EDIT] Now I can tell for sure. It is like 20x slower! [EDIT2] After a while, I interrupted the cloning/pulling, reinstalled python-subvertpy, and continued the cloning/pulling: it apparently worked flawlessly to the end, and very fast (as it was before using python-subvertpy).

  6. Former user Account Deleted

    I've hit the same problem. I get this with:

    $ hg version --svn
    Mercurial Distributed SCM (version 2.2.1+2-91323a78aac2)
    (see for more information)
    Copyright (C) 2005-2012 Matt Mackall and others
    This is free software; see the source for copying conditions. There is NO
    hgsubversion: 312f36a425f0
    Subversion: 1.6.12
    bindings: Subvertpy 0.7.5

    That's a tip version of hgsubversion, but i get the same problem with 1.4 and Ubuntu's packaged 1.3.

  7. Tom Anderson

    [above comment was me, forgot to log in, sorry]

    ... and switching to the SWIG bindings let me pull successfully. Immediately afterwards, verify said:

    $ hg svn verify
    verifying 952a5df9c8d8 against
    wrong flags for: TIMWeb/src/test/java/com/youdevise/ids/utility/
    difference in: TIMWeb/web/test/js/YD/TIM/ReviewIdeasTest.js
    wrong flags for: TIMWeb/web/js/util.js

    It's worth noting that in my case, the failed pull said:

    $ hg pull
    pulling from
    [r103397] stalwar: Samir: Deleted calls to LOAD_TEST.
    3485 TIM/trunk/TIMWeb/web/test/js/YD/TIM/ReviewIdeasTest.js
    ** unknown exception encountered, please report by visiting

    So it does look like something is wrong with the file TIMWeb/web/test/js/YD/TIM/ReviewIdeasTest.js somehow.

    What does this message mean? Is this a problem in the repository, or in my clone? How do i diagnose or fix this?

  8. Tom Anderson

    I got the same blowup again. Again, switching to SWIG let it work. This time, Mercurial's output did not mention any particular file. However, on runnning verify afterwards, i got:

    checking files
     data/DBUpgrade/src/main/java/dbupgrade/ missing revlog!
     data/DBUpgrade/src/main/java/dbupgrade/ missing revlog!

    These files were created recently, but the last changesets to touch them had already been pulled when my pull failed. Furthermore, other files that were updated recently are corrupt - Mercurial is happy with them, but they have quite clearly been updated incorrectly.

    So, although using the SWIG bindings lets the pull complete without reported errors, it absolutely doesn't seem to be a way to really solve the problem. My repository is now silently corrupt, and i am starting to panic!

    EDIT: I cured this by making a fresh clone which only included believed-good revisions (with -r, which implies --pull), and then pulling again. Even using Subvertpy, that worked perfectly, and now is all well. Weird stuff. I rebase a lot (you have to when pushing back to Svn), and i wonder if this is an interaction between hgsubversion pulls and rebases.

  9. Tim Delaney

    Patch at:

    I have a partial fix for this - hgsubversion.stupid now works. At some point mercurial.patch.patchbackend() started throwing mercurial.patch.PatchError instead of returning < 0 so we need to catch that and raise BadPatchApply to fall back to getting the full revision instead of deltas.

    I've tried falling back from Subvertpy to stupid, but I'm getting the following error. I expect I need to drain the command output before falling back to stupid, but I've no idea how.

    abort: ("Unknown status 'textdelta-end' in command response", 210004)
  10. Tim Delaney

    Because of the fallback issue, in I'm just aborting if it would have tried to fall back to hgsubversion.stupid. This allows me to do a loop in a shell script like:

    SCRIPT_DIR="`dirname \"$0\"`"
    cd "${SCRIPT_DIR}"
    REPO_ROOT="`hg root`"
    cd "${REPO_ROOT}"
    until hg pull; do
    	last_pulled="`cat .hg/svn/lastpulled`"
    	next_rev=`expr ${last_pulled} + 1`
    	hg pull --config hgsubversion.stupid=true -r ${next_rev}
    cd "${CUR_DIR}"

    i.e. pull just the next revision as hgsubversion.stupid.

  11. Dennis Schridde

    I have the same issue, also using hgsubversion.

    $ hg pull -u
    pulling from svn+
    [r25195] raster: todo++

    Complete backtrace attached.

    Parameters to apply_txdelta_window were:

    (0L, 6599, 6703, 2, [(0, 0, 1471), (2, 0, 97), (0, 1464, 5135)], 'needs way to replace or extend the right click menu (disable/enable\n rename/delete/refresh etc.)')

    The contents of sbuf are attached.

    This is the code that generated the output:

        f = open("/tmp/hgsvn-params", "w")
        f.write(str((sview_offset, sview_len, tview_len, src_ops, ops, new_data)))
        f = open("/tmp/hgsvn-sbuf", "w")
        if len(tview) != tview_len:
    hgsubversion: e252f9355933
    Subversion: 1.6.17
    bindings: Subvertpy 0.8.10
  12. Log in to comment