What would "help" is agreeing to break compatibility, which would definitely require a fork (or a "version 2.0", which is what the community keeps, in moments of darkest despair, suggesting). But an incompatible Subversion is hardly a Subversion at all (regardless of its name, number, or origin).
Instantiating a fully open core, on which to deliver proprietary add-ons, is a harder model: it requires the implementation domain to actually have such a division, and it requires a lot of investment in that core... probably more than any one company is prepared to spend, merely to release it utterly to anyone's use. There are a few cases where this has worked, notably of course the Apache projects (and most notably, httpd): many companies collaborated to create the core, so they could build value on top (mostly in the form of web sites/applications, rather than httpd add-ons per se, but the economics are the same). But such opportunities are rare.
Careful requirements are certainly important, but so also is competence. No requirements document was ever complete. There will always be decisions to be made beyond the document, and they have to be made with proper respect for the fundamental objectives. The BP is correct: "To have a company intimately involved with *security* not apparently able to manage their own security in a manner that protects the country and their customers is a joke." If not something worse.
> We must begin to boycott these types of unwanted spam.
We have begun. We have made huge strides. We have even invented automated tools to help us boycott these types of (redundantly) unwanted spam. My email provider boycotts hundreds a day for me; my MUA boycotts dozens more; my delete button never tires.
The real problem is that we have to finish boycotting spam, or we don't win! When we boycott Safeway, we only have to keep, say, 10% of their customers out, and they capitulate. But we can, and probably do, keep 99.995% of spam-recipients from responding, and still it's profitable.
One other difference I don't see mentioned: Subversion includes documented, well-designed APIs, at a number of levels. This allows clients to integrate quickly, natively, reliably, and conformantly.
By contrast, CVS... just doesn't. So clients mostly integrate by running a cvs subprocess. This limits what you can do, it also exposes you to all those annoying "file-name quoting" problems.
AFAICT, the only client that has implemented CVS directly is Eclipse. That team has done a manful job, originally and also in support, emulating as best they can the idiosyncrasies of the undocumented CVS client, but it remains an ongoing source of turmoil for anyone running a CVS server and extending it in any way. There are already two Eclipse Subversion clients (a JNI binding to the standard C libraries, and a complete reimplementation in 100% Pure Java), and they're both no trouble at all.
Slashdot Mirror
What would "help" is agreeing to break compatibility, which would definitely require a fork (or a "version 2.0", which is what the community keeps, in moments of darkest despair, suggesting). But an incompatible Subversion is hardly a Subversion at all (regardless of its name, number, or origin).
My research shows World Public Opinion is sponsored by ...
And I think I once even saw a point made without astro-turffing!
My research shows World Public Opinion is sponsored ...
You know, even here in /., it's not absolutely *mandatory* that your arguments be wholly ad-hominem.
Dude! I think you've solved it!
Instantiating a fully open core, on which to deliver proprietary add-ons, is a harder model: it requires the implementation domain to actually have such a division, and it requires a lot of investment in that core ... probably more than any one company is prepared to spend, merely to release it utterly to anyone's use. There are a few cases where this has worked, notably of course the Apache projects (and most notably, httpd): many companies collaborated to create the core, so they could build value on top (mostly in the form of web sites/applications, rather than httpd add-ons per se, but the economics are the same). But such opportunities are rare.
Careful requirements are certainly important, but so also is competence. No requirements document was ever complete. There will always be decisions to be made beyond the document, and they have to be made with proper respect for the fundamental objectives. The BP is correct: "To have a company intimately involved with *security* not apparently able to manage their own security in a manner that protects the country and their customers is a joke." If not something worse.
We have begun. We have made huge strides. We have even invented automated tools to help us boycott these types of (redundantly) unwanted spam. My email provider boycotts hundreds a day for me; my MUA boycotts dozens more; my delete button never tires.
The real problem is that we have to finish boycotting spam, or we don't win! When we boycott Safeway, we only have to keep, say, 10% of their customers out, and they capitulate. But we can, and probably do, keep 99.995% of spam-recipients from responding, and still it's profitable.
By contrast, CVS ... just doesn't. So clients mostly integrate by running a cvs subprocess. This limits what you can do, it also exposes you to all those annoying "file-name quoting" problems.
AFAICT, the only client that has implemented CVS directly is Eclipse. That team has done a manful job, originally and also in support, emulating as best they can the idiosyncrasies of the undocumented CVS client, but it remains an ongoing source of turmoil for anyone running a CVS server and extending it in any way. There are already two Eclipse Subversion clients (a JNI binding to the standard C libraries, and a complete reimplementation in 100% Pure Java), and they're both no trouble at all.