obliterate functionality?

Adrian Buehlmann adrian at cadifra.com
Tue Mar 18 19:01:29 CDT 2008

On 18.03.2008 20:02, Ollivier Robert wrote:
> According to Bruce M Simpson:
>> The lack of obliterate functionality is a real barrier to the possible 
>> future adoption of Mercurial by both XORP and the FreeBSD Project, two 
>> projects where I wear hats, and have been trying to encourage the 
>> adoption of Hg.
> /me raises hand :-)
>> My grounds for advocating "obliterate" in view of those points, are that 
>> in the situations outlined above, people can and do make mistakes, and 
>> even if "obliterate" is not guaranteed to purge all copies of a "leaked" 
>> or otherwise mistakenly committed revision, the accountability is there 
>> and you can say you tried to obliterate the file, regardless of the 
> To add to that, in the past when lawyers asked us (the FreeBSD project) to
> remove code from CVS, they were happy to have it removed the official repo
> regardless of how many copies were duplicated worldwide through our mirrors...

Would it be helpful if we could first think about removing *all* revisions
of a file?

Let's say a lawyer asks a repomaster to stop serving file jerk.c to the world
because of legal issue X. What about removing *all* revisions of jerk.c
from the offending repo?

Of course this would possibly be way too drastic, but I am thinking about whether
partial cloning might lead to a viable solution:

You could then partially clone your repo, leaving away jerk.c and serve that.
The partially cloned repo would need to store the information that it is ok
that the revlog of jerk.c is missing. This would obviously be transitive
(further clones would lack the revlog of jerk.c as well).

Obviously, "hg update" to any cset would then not write jerk.c into your
working dir.

I haven't checked the following:
What can be done with a partially cloned repo? Can we commit to a partially
cloned repo? I mean, are we able to calculate the new hash of a new cset
even though the revlog of jerk.c is missing? (assuming that we don't
try committing a new revision for jerk.c, which is yet another case).

Of course removing *all* revisions of a file might be way too drastic. But it might
be interesting to first think about this as an intermediate step.

Next step might be to think about cutting the revlog of jerk.c at some point,
which means that all revisions of jerk.c *after* revision Y are missing.
The repo would then be partially cloned up to revision Y of jerk.c.

Removing a *single* intermediate revision of the revlog of jerk.c seems
impossibly to me. This would break the hashes of all the revisions *after* the
removed revision.

More information about the Mercurial mailing list