Marcin.Kasperski at softax.com.pl
Wed Mar 19 08:05:35 CDT 2008
Patrick Mézard <pmezard at gmail.com> writes:
> Giorgos Keramidas a écrit :
>> The lawyers don't really care if I have an old copy of user/keramida at
>> home, on my laptop, or archived in a DVD-ROM disk somewhere. They are
>> only interested in making sure that the `Project' is not endorsing or
>> supporting a clone with the obliterated files.
> It's clear that no solution preserving the hashes is likely to come
> up quickly, it's breaking deep invariants which makes it hard to
> implement and it would break existing clients. What about discussing
> real-world use cases instead, so we can come up with better history
> rewriting tools ?
hashes routines work in a stream basis. I can imagine replacing
obliterated file with the information what was its hash and using this
value for further calculation
Say you had changeset [X][B][C] with sum N. X is to be obliterated.
So you just save the state of hash calculation after X is processed,
and since then just start calculation for B and C with different
If it is [B][X][C], then you can preserve separately sum after B for
additional verification, then use the partial sum after B and X as
(yeah, I know, that is just very looose idea, not sure how difficult
would it be to implement this)
More information about the Mercurial