Issue #294 open

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

sergey
created an issue

Hi, this is Mercurial 1.8.4 and Subversion server 1.6.15 on Linux. I filed 805784 (https://bugs.launchpad.net/subvertpy/+bug/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 delta.py, 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. 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.

  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. Bruno 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).

  5. Anonymous

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

    $ hg version --svn
    Mercurial Distributed SCM (version 2.2.1+2-91323a78aac2)
    (see http://mercurial.selenic.com for more information)
    
    Copyright (C) 2005-2012 Matt Mackall and others
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    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.

  6. 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 http://srcctrl.youdevise.com/opt/repo/projects/TIM/trunk@103391
    wrong flags for: TIMWeb/src/test/java/com/youdevise/ids/utility/EntitlementsTest.java
    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 http://srcctrl.youdevise.com/opt/repo/projects/TIM
    [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?

  7. 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/ViewStateIdeaStateEnum1.java.i@17535: missing revlog!
     data/DBUpgrade/src/main/java/dbupgrade/ViewStateIdeaStateEnum2.java.i@17535: 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.

  8. Tim Delaney

    Patch at: https://bitbucket.org/magao/hgsubversion/changeset/0937c3075ce332f1c3aafeec804c165d50057657

    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)
    
  9. Tim Delaney

    Because of the fallback issue, in https://bitbucket.org/magao/hgsubversion/changeset/58a03911780a29d3fc76d499c89744fc636ec3d7 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:

    CUR_DIR="${PWD}"
    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}
    done
    
    cd "${CUR_DIR}"
    

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

  10. Dennis Schridde

    I have the same issue, also using hgsubversion.

    $ hg pull -u
    pulling from svn+http://svn.enlightenment.org/svn/e
    [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.close()
        f = open("/tmp/hgsvn-sbuf", "w")
        f.write(sbuf)
        f.close()
        if len(tview) != tview_len:
            [...]
    
    hgsubversion: e252f9355933
    Subversion: 1.6.17
    bindings: Subvertpy 0.8.10
    
  11. Log in to comment