4

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?
codekaizen
  • 26,990
  • 7
  • 84
  • 140
  • What is the purpose of the pure-Hg repo? The normal workflow with interfacing Hg into SVN is to do as you do on the SVN-track repo. Make changes, pull from SVN, rebase, push to SVN. – Steve Kaye Dec 01 '11 at 08:20
  • The pure-Hg repo is to be able to live in the Hg world, where I can have full-fidelity history, multiple branches, bookmarks, etc. I grew more and more discontent with the "normal" workflow the more I learned what I was missing. – codekaizen Dec 01 '11 at 08:58
  • Unfortunately, I don't think that you can do that when working with Subversion. You have to rebase to get the history in a state that it can understand and rebasing is only supposed to be done when you **know** that the history you are changing hasn't gone anywhere. In your case you know the exact opposite. The pure-Hg repo has the original history and so pulling/pushing between the two is always going to cause problems. – Steve Kaye Dec 01 '11 at 09:14
  • 1
    But why do I (via hgsubversion) need to pull back from SVN the changesets I push? Since they are atomic commits, why can't I just assume they will be the same, and just map the changesets I push to SVN to the SVN revision without pulling and stripping the originals? – codekaizen Dec 01 '11 at 09:23
  • It's not the hgsubversion part that is not working - that just gets the new changes as it should. It is the fact that you have two linked Hg repos and that you are modifying the history in one and not the other. This is an accepted no-no of all DVCSs (as far as I know) – Steve Kaye Dec 01 '11 at 09:57
  • That's the easy part - I can use `hg graft`. The problem really is the duped changesets from hgsubversion. – codekaizen Dec 01 '11 at 10:10
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/5494/discussion-between-steve-kaye-and-codekaizen) – Steve Kaye Dec 01 '11 at 10:29

1 Answers1

0

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.

Paul S
  • 7,645
  • 2
  • 24
  • 36
  • If there have been other changes in SVN before, SVN will not allow the push/commit. It will complain about File '/home/sally/svn-work/sandwich.txt' is out of date – OK. Dec 01 '11 at 14:17
  • But why not just a pull-rebase? Sure there are other changesets, but hgsubversion makes me pull and rebase anyway, why not just say that the changesets I'm pushing and then which exist in SVN are the changesets I have? – codekaizen Dec 01 '11 at 16:16