obliterate functionality?

[Andreas Axelsson]

Sounds like there are two scenarios here:

1. Get rid of sensitive material. Well, if it's in the wild, tough luck, it
can't be done.
2. Get rid of payload which hogs the repo for no good reason. It'll still be
in the wild, but I can ask people to grab the new "slimmed" repo to save
themselves a bunch of space. I'd have to monitor any pull for the junk, but
that may be possible to automate, right?

/axl

On Tue, Mar 18, 2008 at 8:39 PM, Martin Geisler <mg at daimi.au.dk> wrote:

> Bruce M Simpson <bms at incunabulum.net> writes:
>
> > 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.
>
> It is not just difficult to remove a piece of data form a distributed
> system, it is really *impossible*. If people have gotten hold of your
> data you have no way to force them to delete it. The data might be on an
> unplugged USB device, etc...
>
> > 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).
>
> It sounds like you want the backout command:
>
>    hg backout [OPTION]... [-r] REV
>
>    reverse effect of earlier changeset
>
>        Commit the backed out changes as a new changeset. The new
>        changeset is a child of the backed out changeset.
>
> It lets you mark a change as a "mistake" by committing a counter-change
> which, when people pull it, will reverse the mistake.
>
> The original mistake and the correction are of course still present in
> the repository, people can look at them with 'hg view', etc., but people
> who pull from the repository will not be affected by the change anymore
> since you have corrected it.
>
> --
> Martin Geisler
>
> VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
> SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20080318/33fff92b/attachment-0001.html>