为什么我要弃用 SVN，而启用 GIT 和 DVCS

The first core reason to switch from SVN to GIT and DVCS

Is it not better to have the functionality and not need it, – than someday need the functionality and not have it?

We all know that feeling when you could have done something that could have prevented a huge problem, you just want to kick yourselves when that critical moment occurs and when the consequences come crashing down. The problem is that there is a general ignorance about the benefits of GIT and DVCS over SVN, well this is one occasion that the saying „what you don’t know can’t hurt you” certainly does not apply.

So in the interest of preventing those SVN users out there from kicking themselves, – below is a bullet point list of the main reasons of why to change to GIT and DVCS, after all, – we don’t want SVN users to hurt themselves.

• SVN Remote Depositories are slow and prone to the failure of networks. GIT and DVCS are faster and the failure of remote networks is not an issue because a local repository with local history is used.

• SVN Data files are cumbersome and bloated and therefore difficult to work with.

• GIT improves Code Quality because the decentralized repository allows users to add validation and workflow rules. Pull requests, code reviews, voting systems along with the critical authorization systems add a layer of checks and balances on code quality before the merging with the master repository. This is a huge advantage over SVN.

• The Functionality of GIT is far superior to SVN. GIT fully supports Rebasing, merge algorithms and conflict resolution. The features of SVN are inferior or nonexistent in every way.

• Stashing is an attractive feature of GIT that SVN simply does not have the ability to switch from working one part of a project to another or start a new one, – to pause work, save any modifications locally and then resume later, prevents the conflicts that usually arise with SVN. (edit both SVN and CVS have copied this feature by bolting on an inferior (in our view) ’local commit’ option).

• GIT is constantly updated adding new features whereas SVN is slow, always playing catch up (which they have not yet come close to matching GIT – the undisputed market leader).

• With GIT there is complete support for deleted and renamed files with a clear history of any changes made. This allows for continuous file change management, which is just not practical with SVN.

For those SVN users that don’t like or perhaps fear change, the good news is that you can use GIT on the same repository that you use SVN, so you can use them in parallel and therefore there is no need to quit one to adopt the other. Continue with SVN and adopt GIT and once the learning curve is overcome abandon SVN (see Git SVN commands).

In the interest of balance it is only fair to mention the failures of GIT, these include:

• No collaboration feature

• GIT workflows are limited; one example of this is patch files

• For Enterprise use GIT is limited to small teams. For larger teams GITs security, collaboration and workflow features are just insufficient.

The failures of GIT might be considered terminal where enterprise use is concerned and indeed, be used as an argument for continued use of SVN, however this would be an error, a flawed argument.

codeBeamer ALM software – Mercurial, SVN and GIT

codeBeamer ALM software extends GIT with enterprise security, collaboration and workflow features. There is no need to compromise on functionality and security since codeBeamer ALM provides the functionality that GIT lacks. Intland Software does not limit users to GIT or SVN with codeBeamer ALM, we provide the freedom of choice, fully supporting Mercurial, SVN and GIT, however we advise GIT, DVCS and codeBeamer ALM for enterprise use. There is no longer a reason to use SVN and every reason to use codeBeamer ALM software.