I think you assumed I meant 'DVCS like local copies of the repository history' when what I actually wrote was 'local history---a little like DVCS'. I confess that the added 'a little like DVCS' could be misinterpreted. There have been plenty of announcements about Subversion 1.7 changes to the working copy...
Like this.
Looks very much like an announcement on the Subversion Community site (which is sponsored by your organisation isn't it?) that the Subversion 1.7 will have...
Next Generation Working Copy (WC-NG), enhancing the existing working copy functionality with centralised metadata storage and improved extensibility. This will provide the groundwork to allow offline commits and other features associated with Distributed Version Control Systems (DVCS) such as Git and Mercurial.
Oh, and here's the original press release from WANDisco.
While details are a bit sketchy, "offline commits" and " other features associated with Distributed Version Control Systems", to me, implied maintaining at least a simple working copy history. What use would an "offline commit" be if it did not maintain a local history of these "offline commits"? I think that, in light of this announcement, my observation that there were moves to make '... Subversion working copies maintain local history---a little like DVCS' was not unreasonable.
And this presentation (pages 12-16) in which the idea of "shelving" ("Offline commits") is once again mentioned.
And this article (scroll down to section 2 "SVN vs. GIT, Mercurial and Bazaar", which again mentions shelving and "distributed VCS storage".
There's plenty more, just Google "Subversion 1.7". As I said, I may have misinterpreted what "offline commit" means, but if it does not mean some sort of locally maintained history what use is it?
As for the rest, it was not my intention to start a long debate about the relative merits of DVCS versus central server VCS. I am more than happy to have that debate and I see much merit in both models. I would suggest however that we take any future debate over to the General forum where it will enjoy a larger audience and more participants.
Briefly, to your point about a full history being more useful to a miscreant than a 'sandbox' because they could (with sufficient patience and skill) divine management intentions etc. from such a repository. What you say is true of course, but any machine that exposed such a repository would probably contain information of that sort in a much more readily accessible form (emails, developer notes, meeting minutes, documentation, models, plans, etc.) Any organisation concerned in the slightest about laptop security uses low level encryption systems like SafeBoot (I think it's now called McAfee Endpoint Encryption) to protect the whole asset, so the concerns about information falling into the wrong hands are moot aren't they? This whole "you have your entire product history on the laptop" is a bit of a red herring. Security should be much better than relying on the fact your developers are only carrying around part of your code's history.
Besides (while we're conjuring bogey men), in most organisations where I've used Subversion the developers cache their username/passwords. If we're dreaming up a bad-guy smart enough to divine management intentions from a code base, then I suggest he's also smart enough to not even bother stealing the laptop, he just copies the user's cached credentials and then merrily surfs around the central repository. (And yes, there are plenty of ways to protect against this risk, but then we were positing an organisation so dumb they would not encrypt laptops holding their code base and other IP.)
I never said 'DVCS isn't stored in silos', I said 'It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers"'. I was making an observation about the tone of the message, not the fact of it (although I do challenge the implications of what you wrote).
My original point was not to favour one solution over the other (I really don't, I like to understand the problem to be solved before deciding on the solution), but to point out that a blanket statement that "solution X" is right and "solution Y" is wrong without knowing the specifics of a situation was rather silly.
Okay, if you're interested in a debate about the relative merits of different approaches to version control, then please address it on the General Forum where I'll be happy to engage (and I am certain you will get many more different, interesting, and heated, views on the topic from the very smart and well informed CM practitioners who hang out there).
