[Python-Dev] Hg: inter-branch workflow

[R. David Murray]

On Thu, 17 Mar 2011 14:33:00 +0100,  wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
> > 
> > It would be great if rebase did work with share, that would make a
> > push race basically a non-issue for me.
> 
> rebase as well as strip destroy some history, meaning some of your
> shared clones may end up having their working copy based on a
> non-existent changeset. I'm not sure why rebase would be worse that
> strip in that regard, though.

Well, it turns out that this completely doesn't work, though at first
it appeared to (and so I pushed).

I had a push race, so I did hg pull; hg rebase.  Then I looked at the
log, and I could (apparently) see my change sets on the top of the
stack.  So I pushed.  Victor then asked why one of my commits deleted
Tools/demo/README, and then the next commit restored it.

What I was attempting to push was a doc change in 3.1 that I had then
merged to 3.2 and default.  What I saw when looking closer at the log
(after Victor pointed it out) was that my merge commits had lost their
parents.

I thought that at worst a rebase would screw up my local history, but
apparently I managed to push some sort of damaged history.  The doc
change only got applied to default, since that's the branch I
happened to be in when I did the rebase.

Needless to say, I'm avoiding rebase henceforth.

I don't think this had anything to do with share, by the way, but rather
the fact that I had merge commits before I did the rebase, and that
rebase apparently operates on branches, not the repository has a whole.
It would have been nice if rebase had refused to run given that
there were merges, since it clearly doesn't work in that case.

I'll backport the doc change tomorrow :(

--
R. David Murray           http://www.bitdance.com