peter.arrenbrecht at gmail.com
Wed Mar 19 12:08:28 CDT 2008
On Wed, Mar 19, 2008 at 2:05 PM, Marcin Kasperski
<Marcin.Kasperski at softax.com.pl> wrote:
> 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
> starting value....
> 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)
I was thinking along the same lines. An `hg verify` would then have to
tell you that obliterated.c was, in fact, obliterated when it skips it
using remembered intermediate hashing values. You'd have to decide for
yourself if you wanted to trust a repo with such messages. To
alleviate this, we could add a file, .hgobliterates, with accepted
obliterates. This file would be version tracked normally and its
commits would thus tell openly about obliterates and their reasons.
More information about the Mercurial