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