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

[Kevin Bullock]

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?

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock