rebase now aware of subrepos breaking hgsubversion

[Matt Mackall]

On Tue, 2012-04-17 at 17:04 -0500, Augie Fackler wrote:
> On Apr 17, 2012, at 5:02 PM, Matt Mackall wrote:
> 
> > On Tue, 2012-04-17 at 16:25 -0500, Augie Fackler wrote:
> >> Patrick, put you on the To line since you're the one that knows the most about externals here (I think).
> >> 
> >> hgsubversion's tests broke a couple of months ago against tip of main, but I've not had a chance to look at it until now. The result of my bisect run is
> >> 
> >>> The first bad revision is:                                                      
> >>> changeset:   16073:b254f827b7a6
> >>> user:        Matt Mackall <mpm at selenic.com>
> >>> date:        Mon Feb 06 15:10:01 2012 -0600
> >>> summary:     subrepo: rewrite handling of subrepo state at commit (issue2403)
> >>> 
> >> 
> >> which makes me thing we need to do something smarter when we rebase
> >> changes that involve .hgsubstate. When I added some hacks to the
> >> failing test so I could see the result of the rebase, I ended up with 
> > 
> >>> diff --git a/.hgsubstate b/.hgsubstate
> >>> --- a/.hgsubstate
> >>> +++ b/.hgsubstate
> >>> @@ -1,3 +1,3 @@
> >>> -HEAD dir/deps/project2
> >>> -HEAD subdir1/deps/project1
> >>> -HEAD subdir2/deps/project2
> >>> +2 dir/deps/project2
> >>> +2 subdir1/deps/project1
> >>> +2 subdir2/deps/project2
> >> 
> >> which I'm pretty sure means that when we did the local[0] commit
> >> operation, hg wrote an exact revision number to the hgsubstate rather
> >> than HEAD. Does it seem reasonable to "fix" subrepos so that if a user
> >> (or a tool in this case) specifies HEAD as a revision in hgsubstate we
> >> don't clobber it with a fixed number?
> > 
> > No, that doesn't see right to me. The .hgsubstate file is a black box
> > owned by Mercurial and if you stick your fingers in there, you shouldn't
> > be surprised if you get bit.
> 
> I wasn't clear: I meant that we should fix Mercurial's implementation
> of subrepos to support a notion of "don't rewrite this, it's a magic
> value" revision identifiers so it wouldn't rewrite HEAD into a number.

No, you were clear. But my knee-jerk reaction is that sticking HEAD in
there is Just Wrong. We're always telling people "no, subrepos are NOT
for automatically getting the latest versions of other projects, that's
not Version Control™", and that's the only reason I can think of for
want to put HEAD in there in the first place. Am I wrong?

-- 
Mathematics is the supreme nostalgia of our time.