Different hashes for the same patch

[Carl-Daniel Hailfinger]

Hi Jeremy,

On 03.01.2010 23:52, Jeremy Kerr wrote:
>> Any ideas how to solve this?
>>     
>
> The correct fix would be to specify the ordering in the hash calculation 
> algorithm (ie, reorder the diff, sorting by filename, then calculate the 
> hash).
>   

Agreed. Sort by filename or sort by path? I'm thinking of the special
case of file creation/deletion where most (all?) VCS give the name
/dev/null to the empty instance of the file. For this case, the sorting
would have to pick the non-/dev/null filename to resolve ambiguities.


> However, this will break the calculated hashes in exsisting patchwork 
> databases. There's a script to do this (apps/patchwork/bin/rehash.py), but may 
> require some coordination with upgrades.
>   

Hm. If we store old and new hashes for each patch in the database, it
should be possible to have the client use a new hash function and
resolve it without ambiguities over the wire. Kind of like
patch_get_by_project_hash and patch_get_by_hash. The big problem is of
course if someone runs (on a new local patchwork install)
apps/patchwork/parser.py --hash
and feeds the result to pwclient. In that case, it is not practical to
print multiple hashes, so a fallback for older patchwork servers is more
difficult. The only way out I can see right now is to combine (append)
old and new hash for  "parser.py --hash" and have pwclient pull it apart
again. This is a lot of pain for backward compat, though

I'm sorry, I don't have a good answer.

Regards,
Carl-Daniel

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."