StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>First, let me say what a pleasure it was to read such a detailed question write up. :)</p> <p>The problem is happening when you do the <code>hg push</code> to the svn repo from remote. Here's that output from your example:</p> <pre><code>hg push pushing to svn://... searching for changes [r3834] bmurphy: database namespace pulled 1 revisions saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp adding branch adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files rebase completed </code></pre> <p>I'm not a hg-subversion user, but that output says that in the process of doing the push you requested, it's pulling the changes from the svn repo, finding a new revision and then doing a <code>rebase</code> of your changeset <code>10c1</code> after (descendent of) the newly pulled revision. The <a href="http://mercurial.selenic.com/wiki/RebaseProject" rel="nofollow noreferrer">rebase command</a> takes branching histories and turns the into linear histories, but in doing so it changes the parents of the changesets, which changes their hashes, which looks like just what's happening to you.</p> <p>Again, not a hg-subversion user, so I can't say if that pull/rebase is always supposed to happen and how that's supposed to work, but the <a href="http://bitbucket.org/durin42/hgsubversion/wiki/Use" rel="nofollow noreferrer">hgsubversion</a> wiki page says:</p> <blockquote> <p>You can use the usual Mercurial commands to work with this repository. If you have a series of commits on a given branch, and want to move them to the tip of that branch, use the hg rebase --svn command while on the tip of your work, and those changesets will automatically be rebased over top of the new upstream work.</p> </blockquote> <p>which makes it sound not normally automatic.</p> <p>I couldn't quite tell from your intro, are new changesets still being created in svn, or are they created only in mercurial?</p> <p>If they're only created in mercurial then one work-around would be to set up a svn-gateway repo on the remote system, and do the push from there, and never pull from that repo back into mercurial. Then the changesets in that repo would have different hashids due to the rebase, but they'd not flow back into the main remote repo and the end user systems.</p> <p>The bigger fix though is to figure out why "hg push svn://.. is rebasing all the outbound changesets". Answer that one and the behavior will stop.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload