On projects and their goals

Posted Apr 6, 2010 4:12 UTC (Tue) by lambda (subscriber, #40735)
In reply to: On projects and their goals by neilbrown
Parent article: On projects and their goals

Actually, you can't really "obliterate" in Subversion (or any other centralized VCS) either. People can still have checkouts of old versions on their machine. I can't be the only person who, due to various limitations of Subversion (such as lack of "git stash" functionality, and how slow it is to switch between branches), would frequently have several checkouts at once, along with a directory full of patches that might not be ready to apply yet, or might be an idea that never went anywhere that I might try to revive later. And some of those checkouts would eventually go stale, perhaps for years. Unless you have some way of tracking what developers have checked out on their machines, you can't really obliterate old revisions any better in a centralized system than in a DVCS.

What you can do, in either system, is rewrite the history on the official server copy. Then, in the DVCS, you have people make fresh clones, which won't share history. If people have stale copies on their machine, that's their responsibility; if it's such a liability that you must delete all stale copies, then you will need to have IT come and scan all developers machines for the offending code whether you're using a centralized system or a distributed one.

to post comments

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

Posted Apr 6, 2010 6:46 UTC (Tue) by khim (subscriber, #9252) [Link] (9 responses)

And some of those checkouts would eventually go stale, perhaps for years.

They can go stale with SVN, but not with P4. Unlike SVN P4 keeps track of all checkouts on server (thus avoiding .svn madness) and if the client is not used for some time P4 admin will ask you to remove it. Plus server knows if you've checked out the obliterated file or not. And company can enforce the policy that checkouts can only go to NFS share - then files can be tracked even there.

In short: it's hard to make 100% reliable "obliterate" feature (you can always use your phone to take the photo of obliterated file and it's kinda hard to prevent that unless you are working in prison), but centralized VCSs are 100 times better then DVCS here...

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

Posted Apr 6, 2010 18:00 UTC (Tue) by ebiederm (subscriber, #35028) [Link] (8 responses)

I can not even fathom the use case that would be so important, that someone would optimize for being able to destroy all traces of time consuming expensive work.

Were you talking rhetorically or is there some case where obliterate is the key feature needed from a version loss^Wcontrol system?.

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

Posted Apr 6, 2010 18:27 UTC (Tue) by mrfredsmoothie (guest, #3100) [Link]

Code w/ comments which violate company policies (e.g., hate speech);

Code which divulges proprietary company information (e.g. trade secrets);

Code which divulges information the company is not allowed to divulge for regulatory reasons (e.g. Protected Health Information or sensitive financial data).

That was just 3 off the top of my head, took < 30 seconds. I'm sure there are many more.

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

Posted Apr 6, 2010 19:20 UTC (Tue) by foom (subscriber, #14868) [Link] (6 responses)

I have needed to destroy information from an SVN repository once. Someone committed stuff
which could not be left available, for legal reasons.

Despite not officially having support for such a thing, it was not too difficult to do manually. The
data was removed from the central repo, so if you tried to get an old revision, you got an empty
file, and as soon as people updated their checkouts, it'd be removed there. The clients just
picked up normally from the modified repository without a hitch.

Doing the same with a DVCS would be trickier: you need the explicit cooperation from all users
and need to proactively notify everybody that trunk has been rebased and so they need to rebase
all their branches and force pulls. (and also implicitly, that they should go look for the thing that
was removed to see what was so important as to require breaking everything).

Whereas with SVN, just normal user behavior of updating periodically will cause the data to
naturally disappear without having to bring undue attention to it.

To be fair, I don't think that was ever a design goal of SVN, they just happened to not put
sufficiently paranoid checksumming in it. But it is convenient. :)

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

Posted Apr 7, 2010 21:04 UTC (Wed) by lmb (subscriber, #39048) [Link] (3 responses)

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...

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

Posted Apr 8, 2010 13:43 UTC (Thu) by jengelh (subscriber, #33263) [Link] (1 responses)

>I have needed to destroy information from an SVN repository once. Someone committed stuff which could not be left available, for legal reasons.

There we are again. Review is _golden_, and the git-style "please-pull" model wins. You don't even get to have stuff merged that is obviously not ok (such as hate comments as a parent post described). And if you happen to have commit rights to the central location (in other words, being the maintainer), well, make it company policy that everything must have been reviewed before merging/pushing out.

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

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

Mistakes happen even with the utmost care, and have to be corrected after the fact. It can be done in git (using git filter-branch, aptly called "the nuclear option to history rewriting" by Pro Git). That doesn't mean it should be a streamlined command, as it will be used very rarely (if not, rethinking your workflow is in order, IMHO).