[PATCH 2 of 2 RFC] mq: ignore subrepos (issue2499)

[Matt Mackall]

On Wed, 2010-11-17 at 11:36 -0600, Kevin Bullock wrote:
> On Nov 17, 2010, at 6:19 AM, Patrick Mézard wrote:
> 
> > Le 17/11/10 06:58, Nicolas Dumazet a écrit :
> >> On Tue, 16 Nov 2010 13:13:31 -0600
> >> Kevin Bullock <kbullock+mercurial at ringworld.org> wrote:
> >> 
> >>> # HG changeset patch
> >>> # User Kevin Bullock <kbullock at ringworld.org>
> >>> # Date 1289934367 21600
> >>> # Node ID 98ef79b835aab117950f320da3abb06c2d013a58
> >>> # Parent  742ab7cea58e8ca3aaea5d5d4b4fa0e252f9389e
> >>> mq: ignore subrepos (issue2499)
> >>> 
> >>> If MQ allows modifying .hgsub or .hgsubstate in a patch, it can easily
> >>> lead to an inconsistent subrepo state. This patch prevents qrefresh from
> >>> adding any modifications to .hgsub or .hgsubstate to a patch. The user
> >>> is warned that these files are not included in the patch.
> >> 
> >> Good. Thanks for working on this, I like the idea.
> > 
> > I don't, based on my experience with hgsubversion externals handling.
> > 
> > From http://mercurial.selenic.com/bts/msg14431:
> > 
> > Here is my use case: I work with "proj" which depends on "lib". I want to
> > implement a new feature in proj which requires a more recent lib. I update
> > lib revision (but lib is clean), work on my feature. At this point I want to
> > qnew and switch back to something else.
> > 
> > This case seems perfectly legit and in fact I do that daily with
> > hgsubversion which has something a similar to subrepo to handle
> > svn:externals. There is no problem with MQ because:
> > - The externals state is completely defined in .hgsvnexternals, including
> > the target revision. After editing it, users have to explicitely update the
> > externals using another command. hgsubversion does not automatically record
> > stuff on commits.
> > - We do not care about externals dirtiness.
> > 
> > Instead of preventing MQ to handle subrepos I suggest that:
> > - MQ aborts if any subrepo is dirty before creating/amending a patch
> > - MQ updates .hgsubstate when creating/amending a patch
> 
> 
> This is actually the behavior I expected originally (well, the 2nd
> point anyway), which led me to trip over the bug in the first place.
> The ultimate goal is consistency, and I think your approach maintains
> that. Even though patch operations on subrepos themselves don't make
> sense, the state-of-subrepos is really a property of the _outer_ repo,
> which the patch queue can operate on perfectly well while maintaining
> consistency. Unless I'm missing something?

It seems plausible.

-- 
Mathematics is the supreme nostalgia of our time.