[patch] mq: .hg/patches/status -> .hg/mqstatus

[Hermann Lauer]

On Tue, Aug 24, 2010 at 02:29:24PM +0200, Mads Kiilerich wrote:
> >Rationale is that with mq there are two nested repositories, and the
> >data of the (mq)status file belongs to the outer repository, as
> >the contained hashes are defined in terms of the outer repository
> >and has no meaning without the outer repo.
> >
> >Sounds the proposed move of the (mq)status file feasible ?
...
> You will get unexpected problems anyway if you have the same patch 
> applied in two repos and edit it in both places. To handle such 
> conflicts you need some kind of versioning of the patch queue - and that 
> is exactly what we have and is the recommended solution to the problem.

That's exactly the reason why the .hg/patches is also a repo and we have
nested repositories - so patches can be tested in parallel. Unpatching
(hg qpop) works by reverting the outer repos, so I have no problem
there. Of course, if a edited patch don't "hg qpush" any more this
will be told and has to be fixed, if intended. If not, I simply
throw that repository away.

Using your advise with pushing and pulling of the inner (patches) repositories
involves a lot of additional commands which is what I try to avoid
with my working sheme.

> Moving the status file will not be backward compatible and is thus not 
> an option.

Thats indeed a problem if you have patches applied during an upgrade,
but reading .hg/patches/status after not finding a .hg/mqstatus
should be possible.

> But couldn't you just create the status file as a symlink?

Tried before patching mercurial 1.5x and that did not work
(because of the auditing stuff, if I remember correctly).

Other comments ?

Thanks,
 greetings
   Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer at iwr.uni-heidelberg.de