[PATCH 1 of 1] subrepo: check for dirty warns on missing revision instead of abort

[Friedrich Kastner-Masilko]

Zitat von Matt Mackall <mpm at selenic.com>:

> This patch seems unnecessarily complex. Does this do what you want?
>
> diff -r 9bbac962f4dd mercurial/subrepo.py
> --- a/mercurial/subrepo.py	Thu May 12 20:27:35 2011 +0200
> +++ b/mercurial/subrepo.py	Thu May 12 18:27:46 2011 -0500
> @@ -408,7 +408,7 @@
>          if r == '' and not ignoreupdate: # no state recorded
>              return True
>          w = self._repo[None]
> -        if w.p1() != self._repo[r] and not ignoreupdate:
> +        if r != w.p1().node() and not ignoreupdate:
>              # different version checked out
>              return True
>          return w.dirty() # working directory changed

Hm. While it certainly looks much more elegant, it is not the same  
behaviour. The problem I have with this is the lack of warning on "hg  
update".

With my patch, doing an "hg up" after the subrepo stripping will  
result in a warning, telling the user that something is wrong. Your  
patch is not showing this warning, it just quietly updates the  
superrepo to the specified revision.

IMO this is bad in situations like so:

@ 3: content C, subrepo-hash B
|
o 2: content B, subrepo-hash B
|
o 1: content A, subrepo-hash A

Let's say the user is at 3, like depicted above. If he now strips away  
hash B in the subrepo, a "hg up 2" will bring his superrepo to parent  
2, but will not inform him of the missing states in the subrepo with  
your patch. If the user now does a "hg st", he will get the warning,  
although the previous update succeeded.

The real troublemaker - the abort that makes "hg up -C" impossible -  
is of course eliminated in your version, too.

On a side note: in fact I just copied the behaviour of  
hgsubrepo.diff(), as I thought the catch-clause with the warning  
message fits the situation here, too.

regards,
Fritz