Pushing multiple revs fails with "abort: unknown revision"

Create issue
Issue #52 closed
Luke Opperman created an issue

This looks like issue 51, except that after erroring the first revision is properly pushed and the second is just waiting - a second "hg svn push" is successful.

hg svn 906d3f302b45 mercurial-crew 878466138b57

Comments (10)

  1. Augie Fackler repo owner

    I just got this by pushing a single rev that was not committed over the tip of the svn parent. That might be the cause.

  2. Steffen Hoffmann

    While #133 was marked as a duplicate I see some substantial differences, especially as it suggests to 'hg rebase --svn' instead of just a second push command.

    Mirroring a 8000+ changesets repo I had the issue while trying to push two revisions at a time. First changeset got to repo, second hanging:

    Übertrage nach svn+http://trac-hacks.org/svn/
    searching for changes
    [r8200] hasienda: WikiTicketCalendarMacro: Add pre-compiled regex for performanc
    pulled 1 revisions
    merging wikiticketcalendarmacro/trunk/wikiticketcalendar/locale/de/LC_MESSAGES/wikiticketcalendar.po
    merging wikiticketcalendarmacro/trunk/wikiticketcalendar/locale/ja/LC_MESSAGES/wikiticketcalendar.po
    merging wikiticketcalendarmacro/trunk/wikiticketcalendar/locale/messages.pot
    merging wikiticketcalendarmacro/trunk/wikiticketcalendar/macro.py
    Speichere Bündel in /data/trac/th_devel/hgsubversion/.hg/strip-backup/fffd0639ccb3-temp
    füge Zweig hinzu
    Füge Änderungssätze hinzu
    Füge Manifeste hinzu
    Füge Dateiänderungen hinzu
    Fügte 3 Änderungssätze mit 8 Änderungen zu 7 Dateien hinzu
    Rebase abgeschlossen
    Abbruch: Unbekannte Revision '301aa1bc3637706f4e37a636968da5c3f1122eec'!

    Instead of searching now I kind of panicked then and pushed the changes from the stale revision to SVN directly. Yeah I know, should have done better, anyway. Then I 'hg strip'-ped the problematic revisions from local hg(subversion) repo and tried to pull from upstream SVN to restore - no reaction.

    I don't know right now, how to recover. But at least I know now that this is a known issue. [Edit: Luckily just a matter of stripping down to the right changeset, that is where the branch happened ('hg strip 8200'). Pulling from upstream worked afterwards, as if nothing had happened. Fully recovered. :-)]

    I'll certainly stick to hgsubversion. It's still a great tool and I'll find my way out with it too, no doubt. I like it for good integration within hg and overall good performance (i.e. took only hours to build the SVN clone vs. ~ 3 days and many restarts of hgsvn bailing out after every 100 changesets or so). But I'd really like to see this issue better documented upfront or solved in the first place. Thanks for taking care.

  3. Peter Arrenbrecht

    Here's a test case that reproduces this for me. It goes away if I pull before the push.

    cd ${0/test-merge.sh//}
    rm -rf $d/svn*
    rm -rf $d/hg*
    svnadmin create svnrepo --bdb-txn-nosync
    svn co $u svnwc
    cd svnwc
    f=trunk; mkdir $f; svn add $f
    f=tags; mkdir $f; svn add $f
    f=branches; mkdir $f; svn add $f
    svn ci -m "structure" -q
    cd ..
    rm -rf $d/svnwc
    mkdir svnwc
    svn co $u/trunk svnwc/trunk
    function svnci() {
    	cd svnwc/$1
    	f=$2; echo $f >$f ; svn add $f ; svn ci -m $f --force-log -q
    	cd ../..
    function hgci() {
    	cd hgrepo/$1
    	f=$2; echo $f >$f ; hg add $f ; hg ci -m $f -q
    	cd ../..
    echo '---- establish base history'
    svnci trunk a
    svnci trunk b
    svnci trunk c
    echo '---- branch 2010'
    svn cp $u/trunk $u/branches/2010 -m "branch 2010"
    svn co $u/branches/2010 svnwc/2010
    echo '---- continue working on trunk'
    svnci trunk d
    svnci trunk e
    echo '---- manually backport bugfix to 2010'
    svnci 2010 d
    echo '---- do hg checkouts'
    mkdir hgrepo
    hg clone $u/trunk hgrepo/trunk --startrev 3
    hg clone $u/branches/2010 hgrepo/2010 --startrev 3
    echo '---- hg work on 2010'
    hgci 2010 x
    hgci 2010 y
    echo '---- svn fix with manual merge'
    svnci 2010 f
    svnci trunk f
    echo '---- push hg work on 2010'
    cd hgrepo/2010
    hg push
    cd ../..
  4. StephenKestle
    • removed milestone

    This is caused (for me) by having branches on top of the svn tip. Once I resolve everything to a single commit path (rebasing branching changes onto my local tip) everything works fine, and multiple revisions are pushed

  5. Log in to comment