Well, you can... just not with SVN...

Posted Apr 7, 2010 21:04 UTC (Wed) by lmb (subscriber, #39048)
In reply to: Well, you can... just not with SVN... by foom
Parent article: On projects and their goals

One can, of course, design a DVCS which propagates "poison pills" for changesets (cryptographically signed, if needed, by the one authority that is allowed to), that in the normal course of action removed the offending changeset as they propagate.

Removing the changeset from the history through "rebase-like" can also imply that clients can't pull+merge, but would be forced to clone new.

That, then, requires active intent on the users's side to break, just like SVN right now. Yes, this is more tedious to _implement_, but it need not be more visible to users.

(Of course, none of these addresses outdated working directories nor backup files an editor may have created; if you're worried about legal compliance, you need to scan for the content and destroy it, actively. Regardless of SCM used.)

Well, you can... just not with SVN...

Posted Apr 7, 2010 21:42 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

An explicitly handled poison pills sounds like a quite reasonable way to implement the obliterate
feature in a DVCS. But nobody has done it, yet.

It (like the other features being discussed in this thread) is an important use case that seems to be
widely disparaged by the DVCS crowd as something nobody could ever possibly have a use for. So
it's really nice that Subversion has a goal of catering to these use cases that nobody else seems
interested in even *thinking* about.

Well, you can... just not with SVN...

Posted Apr 8, 2010 16:09 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

A "poison pill" that the poisonee has to swallow willingly, in full knowledge what it is, is kind of pointless for forcing the deletion of certain unwellcome contents... plus won't afect any copies floating around.

Yes, it would be excellent if you could remotely destroy all traces of some secret after the cat is out of the bag... but that just can't be done. Get over it.

Well, you can... just not with SVN...

Posted Apr 8, 2010 21:30 UTC (Thu) by foom (subscriber, #14868) [Link]

I see you don't understand the use case. That does not mean it's not real.

What I'm talking about is within a company, where there is some amount of central control. A
poison pill that the poisonee has to agree to is *not* pointless, if it is processed automatically
and allows the user to not care that it happened. The agreement would happen ahead-of-time,
when the clients are setup to trust the central repository.

Of course it's not possible to (remotely or otherwise) destroy all traces of information. Your
mistake is jumping from that true statement to the suggestion that it's pointless to do anything
at all. And that's simply not a supportable jump. Yes, an Evil User could intentionally save a copy
and Do Evil, but in a corporate environment where you hope you can trust everybody, it's often
quite sufficient to simply avoid explicitly tempting people to do something bad.

At the *very least*, I need to stop distributing the data (that is: remove it from the central
repository). And just that alone will cause significant user pain if everyone's using git. Everyone's
branches and working copies need manual intervention to clean up. Not a fun state to be in.
Contrast with SVN, which implicitly trusts the central repository, and just goes with the flow...