Dealing with duplicated hashes

[Albert ARIBAUD]

Hi all,

Le 15/09/2011 08:10, Wolfgang Denk a écrit :
> Dear Jeremy Kerr,
>
> In message<1316064427.2768.40.camel at pororo>  you wrote:
>>
>>> I came to the conclusion that the current behaviour is actually a bug.
>>> I have seen cases where new patch versions were sent because changes
>>> to the commit message were requested - yet pwclient will always access
>>> the old patch, and thus eventually apply the wrong one.
>>
>> Yeah, bug or not, it's definitely not desirable behaviour.
>>
>> However, solving it in a comprehensive way doesn't seem obvious - we
>> could return an error when there are multiple hash matches, or perhaps
>> default to the most recent patch. But both of these are a little
>> imprescice, will this be okay for your usage?
>
> I think there are two use cases:
>
> - In most cases we want to use the most recent one. So this should be
>    the default.
>
>    If there are multiple hash matches, it would probably be helpful if
>    a warning was issued (which might, for example, contain the numbers
>    of the matching patches and their states).
>
> - In some cases (when changing state) it would be nice to be able to
>    operate on all patches at once; maybe pwclient could have some
>    "--all" flag for such cases?

Sounds good to me, with two nitpicks:

1.

"--all" does not look like it is about matching hashes. I would suggest 
something like "--all-hash-matches" (quite long, I admit) or 
"--all-versions".

But seeing as pwclient seems to be short-option-forms only, I'd settle 
for "-H <hash>" (capital H) for "apply to all patches matching the hash" 
and "-h" for "apply only to the latest patch". :)

2.

When applying state "Accepted" to the newest of hash-matching patches, 
we don't want "Accepted" applied to other matching patches; at most, we 
want them to go "Superseded" -- but I imagine this was implied in 
Wolfgang's suggestion.

> Thanks!
>
> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.