rebase now aware of subrepos breaking hgsubversion

[Augie Fackler]

On Apr 17, 2012, at 5:24 PM, Matt Mackall wrote:

> 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?

I agree with you in spirit, but for hgsubversion this just isn't a workable position. People reference HEAD in their externals definitions and we try to respect that and not break their workflows[0] while we're serving as a gateway drug into the promised land of DVCS and Right-Thinking Version Control. As it stands, this hg-side change is going to break workflows for hgsubversion users that have horrible states involving externals like this. I'd be satisfied with a way to hook into subrepos and override this behavior for hgsubversion[1], but on the other hand it seems like it'd be reasonable to have this as a hidden way for users do do the wrong thing if they really really want to blow their foot off.

[0]: I think Patrick is one of those users. He was, at least, so hopefully he can shed more light on the subject.
[1]: The reality is that we'll probably have to monkeypatch the daylights out of subrepos in hgsubversion to fix this if there's not at least a hook for this, which I'd really rather not do for obvious reasons.