[Monotone-devel] Re: forbid: a (nicer?) alternative to obliterate

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathaniel Smith wrote:
> What about when we are the ones sending the revision, which contains
> the forbidden file, so that our peer is expecting us to send the
> contents of this file but we do not have it to send?

You're right, this can't be STRICTLY local, at least in that case we
must support a "purposefully missing content" message or something.

> Would this feature actually make the people requesting obliterate
> support happy?  For instance, any form of obliterate that is not
> automatically transmitted might be useless to them.

Frankly, I don't know for sure (but I intend to ask, at least some of
them). The problem with "real obliterate" is that it asks for a specific
content to "unexist": i.e. ideally every single copy in every DVD backup
of every single user should automagically change and not contain it (and
in their "wet-wired" memories of it too, possibly).
This is, of course, impossible so maybe (and only maybe) a lawyer (at
least in the case of encumbered content) could be satisfied with a "best
effort" approach that only makes sure the central repository doesn't
have that.

Or maybe not. Maybe they would mandate to recursively delete.
This reminds me the old adage (at least in Italy :P) about long life
elixir: "you mix this with a bit of that and that (stereotypical witch
concoction follows)... but more important of all: DO NOT THINK OF PINK
ELEPHANTS DURING THE PROCESS" (which, of course, you really can't after
you read it once).

> obliterate that leaves behind a cryptographically strong assertion
> that the content _used_ to be there (in the form of continued mentions
> of the file hash in the revision/manifest texts)

Yes, I guess some could argue that the very existance of an hash of that
content means it was there in the first place, but is the problem that
"you can't use that, just avoid using it" (and of course MANY developers
will "notice" and "remember" and probably even have backups, so if the
SCM remembers too doesn't make much of a change, IMHO) or that "it
should unexist"? I wonder.

> Or content might be forbidden because it was proprietary, but
> now the company has decided to release it as FOSS after all

Well I guess in that case it could simply be removed from the "forbidden
list" and it would eventually trickle back in, doesn't it?

> All of these are cases where this doesn't quite work, but I don't know
> if it matters...

Most of those could be solvable using a fully fledged "branch-specific
revision-forbidding policy", but as Paul said, it is overkill to even
think about it, right now.

A provocation: what if a sector of the HDD that contains a specific
version of a file corrupts before content is sync'ed?
Would this be a possible reason that a "expected missing content" (in
this case "missing" would be much better than "forbidden") could be allowed?

    Lapo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJF5SmgAAoJELBiMTth2oCDbaUP/1W4rRK7cQ9YQ7d4+rm2rJOq
uRmQkfz8tD2WsY2h0xAC1pKG1ZqBOReyYu3NzT01kYHVKZ9cJTa7FbYDEKNKGq/m
DbeV3JEo/Xy9SXYWU/9EoB1MuE2Z52/A45s4vElk7rQy/1wQEOP6CEeEzCS8WmC5
4dZbpZZzzrgGX9VdyZGFRRBUJH8GIFTrwJ7u7TzVwhEb11dwoSaOYLXkBUEJ6NBv
F87lvFZJJmKVBjIji0nZVwBsYKzFKBsO/2wf8I5AjLF7Ud8TUXS5r0N9I3iQ7l2G
Iv7NXI0bbFdGJXi5l1zY+bnkz8n6K1q9fQm1hmspfdCA52fTWIOHS7he5JGD34X5
1qAJs20UMMgx1bFgisMf6ICoqze9OK+LFtGnInJCKxQz/62aG81ng6hnuFXr9P1H
5ijlk0aJdeMXWGpqLYOCLQTzxO8KP27ZWOncOrnsYRqRAak4h+NcS1pV4c7ct7PW
yab5189sc6/1jukF1VxKboyjJ9QxU1Lk36xIJle9f4dvoCtwunOATpJJzNaL9VOq
+jdvrMooV9fi7CpHXY+28UOomnU1fCikhLp3RxaZP5i00JXP168WSiOl3KtVwvx1
9mz6eSJSKV7DzVw0c6brWBnT9h578wGRtkgXl1DczzOOofGjTcBpNFCJLHrFz4NG
qy19P1686muBvjU5SGuJ
=9QAR
-----END PGP SIGNATURE-----