rebase now aware of subrepos breaking hgsubversion

[Augie Fackler]

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? That'd fix the problem. The other option would be adding some way for rebase to have filter functions that'd let us elide certain changes during hgsubversion's rebasing process.

Thoughts? This means hgsubversion is "broken" against hg 2.2, so I'm already late in catching something like this before the freeze (which IIRC is today).

[0] local for the hgsubversion repo, but obviously it's a remote operation in the svn subrepo