Bruce M Simpson
bms at incunabulum.net
Tue Mar 18 11:09:07 CDT 2008
>> * 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