obliterate functionality?

Bruce M Simpson bms at incunabulum.net
Tue Mar 18 11:09:07 CDT 2008

cowwoc wrote:
>>     * You accidently checked in sensitive information and need it removed
>>     * You are running a large codebase and need to archive old repository
>> entries to clean up to save drivespace
>>     * You need to split up a repository in several others for some reason,
>> maybe a project needs to be split up
>>     * You accidently checked in large chunks of (unused) information
>> (perhaps some .iso was somehow included), which is sitting there bloating
>> your repository for no good reason
> I have personally run into many of these cases. They might be rare, but I
> strongly advocate that Hg (and others) make it easier to obliterate files
> from the repository so long as you have the necessary privileges.

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.

The same use cases mentioned above in this thread apply to both projects.

I disagree with the argument that "obliterate" is an unnecessary or 
undesirable feature. The grounds given against "obliterate" are that it 
is redundant, or difficult to fully implement in a distributed system, 
or not relevant to such a system.

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 
downstream change-set penalties or the fact that someone now has a copy 
of the file (the "dog ate my homework" argument).

Even if Hg's hypothetical "obliterate" command is of an advisory or 
non-mandatory form, it's better than nothing.


More information about the Mercurial mailing list