[PATCH 1 of 2] mq: reset self.added after the mq transaction instead of inside qimport

Nicolas Dumazet nicdumz at gmail.com
Mon Jul 12 06:03:03 CDT 2010


2010/7/12 Dirkjan Ochtman <dirkjan at ochtman.nl>:
> On Mon, Jul 12, 2010 at 11:59, Nicolas Dumazet <nicdumz at gmail.com> wrote:
>> # HG changeset patch
>> # User Nicolas Dumazet <nicdumz.commits at gmail.com>
>> # Date 1278924923 -32400
>> # Branch stable
>> # Node ID cc85aed7e8df69d1fca77899dc8aadf30b147197
>> # Parent  ee876e42dd742f4dd7d9309cd964733c45e75af6
>> mq: reset self.added after the mq transaction instead of inside qimport
>>
>> It seems wiser to reset mq.added at the end of the mq transaction instead of at
>> the beginning of a qimport call: this way, calling several times qimport()
>> without saving mq state in-between does not overwrite the previous value of
>> mq.added (this happens, for example in rebase, where we import several patches
>> in a batch before calling .save_dirty() )
>
> Sounds good. Are we exposing callers relying on the old behavior to
> any new risks?

For the guys using the "old behavior" before this changeset:

changeset:   11462:1b82a26635d7
branch:      stable
user:        Vishakh H <vsh426 at gmail.com>
date:        Tue Jun 29 03:09:42 2010 +0530
summary:     mq: qimport cleanup on fail (issue2214)

the current code is already broken for them, and they see removed
patches *if* they version them. (same symptom than giorgos's)
After my patch it would be the same.

For the improbable guys relying on the behaviour between vsh and now,
I think that my patch would not change anything for them


But maybe we could be even cleaner, and include the:

        qrepo = q.qrepo()
        if qrepo:
            qrepo[None].add(q.added)
        q.added = []

code into save_dirty() ? This way people using mq internal API _only_
have to take care of this save_dirty step.

-Nicolas.

>
> Cheers,
>
> Dirkjan
>



-- 
Nicolas Dumazet — NicDumZ


More information about the Mercurial-devel mailing list