[PATCH 1 of 2] mq: add qfrozen command to protect patches from careless modification

[FUJIWARA Katsunori]

At Mon, 15 Jun 2009 09:15:02 +0200,
Dirkjan Ochtman wrote:
> 
> On Mon, Jun 15, 2009 at 05:03, FUJIWARA Katsunori<fujiwara at ascade.co.jp> wrote:
> > Thank you for your comment, Ochtman.
> >
> > I assume the use-case that:
> >
> >    1. problem(or new requirement) requires the crossing-patch
> >       modifications.
> >
> >    2. each modifications are closed to others, so once 'qrefresh'ed
> >       accidentally, it is not impossible but trouble to separate them.
> >
> >    3. 'revert' for the patch 'qrefresh'ed accidentally in patch repo
> >       is not acceptable, because it discards intermediate works
> >
> >    4. intermediate 'qcommit' causes creation of BROKEN changeset in
> >       patch repo
> >
> > I think that patch queue versioning does not solve such problems.
> >
> > Of course, if creation of BROKEN changeset is permitted, patch queue
> > versioning is good solution.
> >
> > Is it usual way of patch queue versioning ?
> >
> > Or, are there any solutions/tools for decreasing cost of (2) ?
> 
> I think that it's indeed very acceptable to qci a state of the patch
> queue that is incomplete. Because the changesets have not yet been
> completely committed to the actual history of the parent repository
> (by way of qfinish, mostly), it is clear that the patches are
> in-progress or waiting on some other action (for example, review from
> another team member or a run through a time-intensive test suite). So
> having not-yet-complete patches committed in your patch queue
> repository seems wholly acceptable to me.

By your suggestion, I can figure out difference between usual MQ
use-case and mine.

These are additional assumptions for my use-case:

    - final target platform of product, which is managed by HG, is
      very specific one (e.g.: expensive hardware and/or licensed
      software are required)

    - my client does not want platform portable code, because he
      believes that code for un-supported platform may cause bugs :-<

    - I use MQ patches to adapt product code into un-supported
      platform to test it in popular(and cheap) environment

In this case, adaptation patches are not in-progress work but a kind
of individual product for me.

But certainly, your "patches have not yet been committed to the actual
history of (product) repo" is right.

Mind to treat patches more casually is needed for me, isn't it ? :-)

--------------------
FUJIWARA Katsunori