Surely IDE devs and bugtracker teams could build a decent abstraction layer so that any DVCS would work just fine with them.
I also think that going from no version control to CVS is a larger step than going from CVS to SVN, and that going from CVS to Subversion is a larger step than going from Subversion to Git
But that's only a 'legacy' problem. Today, going from no version control straight to Git/Hg is much easier than even your first step -- and saves you from having to unlearn all that intermediate junk.
I've not used Perforce nor Git
There has been no innovation to speak of in the last ten years
Self-destructive argumentation, on the other hand, is progressing faster than ever!
Published at http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix, "Why free software and Apple's iPhone don't mix" is one of a series of articles detailing the threats posed by Apple's iPhone to the free software community. It focuses specifically on Apple's "tivoization" model of requiring every application installed on the iPhone to have an approved cryptographic signature, a restriction which is incompatible with version 3 of the GNU General Public License and with user freedoms to share and modify free software in general. (emphasis added)
The URL referred to makes this case based on a quote of the GPLv3 "Installation Information" clause,
"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
Even then, I wonder if "incompatible" is not overstating the case. 1) Does conveying here "occu[r] as part of a transaction in which..."? 2) Who exactly is "retain[ing] the ability to install modified object code..."?
I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham