Mercurial + hgsubversion + svn: A tale of 2 repositories… (or, Replace changesets?)

Question

Scenario:

I have 2 Hg repositories: one which tracks an SVN repository, say SVN-track , and a local pure-Hg repository into which I pull changesets from the first.

I push changesets from my pure-Hg repo into the SVN-track repo, then I rebase the pushed changesets in the SVN-track repo until the history is nice and straight, so I can push to the SVN repository.

After I push to SVN, hgsubversion pulls the changeset back from SVN and strips the original changeset. This is how it tracks, I gather (but... why not just keep the original and track it ?).

Problem:

Now, if you've hung on this long, comes the problem: I want to pull SVN changesets back into the pure-Hg repository, but all the original changesets come back as dupes (but with different node ids) on another head. I might be able to rebase all the changesets that I added in the pure-Hg repository, but then I'd lose history and, really, that just seems like way too much work. I could also just live with the pulled-SVN changesets with duplicate content and merge local, but this makes the resulting pushes back to SVN-track harder and harder.

Questions:

• Is there some better way to perform this workflow which I can't divine unaided?
• If not, how do I replace the original changesets that hgsubversion pulls back from SVN in pure-Hg ?
• Why must hgsubversion (a wonderful enabling tool for the most part) pull SVN changesets back just to track them, can't it just keep the original changeset and add a line to .hg/svn/rev_map indicating the original changeset id?
• If so, what is the trick to this?

Answer 1

The reason hgsubversion needs to pull back the changes is (I expect) because there may have been other changes in svn before you made your push. Every commit in svn includes a 'rebase-to-tip' which could effect your changeset. Hence it needs to pull it back to get what actually happened and the new changeset IDs.

Perfarce (the perforce extension) does something similar, but it merges the original changes with the new tip so the graph actually makes sense. There's still duplicates of all the changes I make though.