First we can classify the three tools into two broad categories:

Centralized versioning systems

CVS and SVN have a central repository from where users make the checkout and commit of versioned artifacts.

The advantage of this approach is that you can have central control over the projects, impose access security more easily. In addition, there is the possibility of blocking files (lock).

However, there are many disadvantages. The main one is that this type of system does not scale very well, that is, many teams and projects in the same repository tend to slow it down. Another important disadvantage is that users cannot do much offline , and must always be connected to the central server to perform operations such as creating tags, branches , fazer merge, etc.

Beyond in addition, there are significant differences between CVS and SVN:

• SVN can track renamed files.
• if centralized versioning is slow, CVS can be even more.
• the commit of CVS is per file. SVN can group the changes of a commit, so it is possible for example to go back to a previous revision. This makes it very easy to find which commit broke the code.

Distributed versioning systems

No Git, just like Mercurial and Bazaar, there is no central repository. Of course, you can choose one as such, but each repository, even that of the developer's machine, contains a full and functional copy of the repository.

A disadvantage of this model is that the initial cloning of the repository can take a long time, since not only the current copy of each artifact will be transferred, but also the history, tags and branches. Something that can minimize this it is the possibility to recover parts of the repository selectively, such as branches , tags or even by date. But I don't know details about the extent to which this is implemented in each of the systems.

Another disadvantage is the difficulty of centralized management and effective access control, as repositories are distributed across multiple environments.

Also, on distributed versioning systems, commit and checkout are done in the local repository of each environment. Upon completion of the work, with the class properly "committed", tags "passed" and "merged branches", the developer needs to synchronize his local repository with the remote repository. This is done with the commands push (sends updates from your local repository to the remote) and pull (retrieves updates from the remote repository to the local).

It is a bit more complicated to work with distributed versioning systems, but the advantages are many:

• except the initial pull, they are much faster than centralized systems like CVS and SVN.
• many operations do not require network access, so the developer can work offline, synchronizing with the remote repository only when necessary.
• the developer can work in private mode, generating tags, branches, and versions that will simply be dropped.
• except when there are conflicts, the merge is automatic.
• each copy of the repository acts as a backup of the "main"repository.

Note that there are differences between distributed versioning systems. I know almost nothing about Bazaar, but I can cite some interesting cases regarding Git and Mercurial:

• the git pull command includes the update and updates the files in use of the project, so Git's pull is different from the traditional concept of pull, being equivalent to pull + update. The pure pull would actually be git fetch.
• in Git, You need to manually add the new and changed files to the staging area with the git add command to be "committed". Mercurial does this automatically by default.

A little history

Beginnings

Version control systems are very old. Some of the first known were the CA Software Change Manager, the Panvalet and the SCCS in 1972. Only a decade later came one that formed the basis of how we know these software nowadays with RCS. A few years later an evolution emerged that made the use feasible. But not without problems.

Evolved products

O CVS has been useful for a long time, but it lacks more sophisticated functionality and mostly reliability. It is quite true that in some cases it even works well. But I can't see any reason to choose it these days to manage a codebase of your own. At most use a client to grab code from a legacy project.

Throughout the 80s and 90s there were several commercial software options such as the best known ClearCase, Visual Source [a]Safe and Perforce .

These systems are considered client-server, so you need a central repository to receive all updates. Each with its characteristic, with its virtues and defects managed to greatly improve the workflow of teams developing software.

Something that works well

CVS was very successful because it was open source, but it had many flaws. Not that some commercial products (see joke that I did above) don't have your success either. With this came the SubVersion or simply SVN. An evolution in functionality and reliability over its predecessor CVS.

CVS

So the only thing I'm going to say about CVS is: don't use it, don't waste time on it. It does not have a single simple advantage over its competitors.

The maximum of evolution

Still some projects were not well served by these software. Hence it arises a new generation of products that work in a distributed way, being able to work without a central server (although in practice it ends up having a final server).

This not only enabled work in a disconnected way, more complex interactions between the team and made it possible for teams to have unlimited size, but also added some facilities, making the workflow more organized and flexible, allowing hierarchies of repositories, and especially to do merge , not least because this has become a demand for heterogeneous teams.

For Some examples of such software that emerged in the century are: {[a 49]}at Sun WorkShop TeamWare, Code Co-op, If, GNU-arch - (the first of the open-source), Vm, DVCS, Monotone, Baazar, Git, Mercurial, More (a little bit different than that of its competitors, and that is worth a look), Veracity, Plastic SCM . The latter approximating the two modes distributed and centralized .

Git and Mercurial began to be developed to replace BitKeeper which had a license change. They eventually became the most well-known distributed version control software. And more recently with the growth of popularity of GitHub (central repository web for Git) it has become dominant doing even Microsoft and Google prefer its use over their own repositories. Microsoft ended up buying it.

Popularity

Apart from proprietary software like Team Foundation Server and some less expressive ones, few software has maintained popularity. There is still a good fight between the two modes of controlling versions. SVN became almost the exclusive representative for centralized control and Git shot preference for control distributed, followed by Mercurial, with fewer and fewer followers.

In the background there is a comparison to these two most used and in a way a comparison between the two control modes, because this is what differentiates them the most.

I particularly like the simpler systems (centralized control), although I admit that some features of the more complex (distributed) systems are highly desirable. That's why I like solutions that try to put both together, so I always got along with SVN and Mercurial.

But I also admit that it gets more and more complicated not to look at Git. Having such a popular repository and having more and more good integrations with other tools makes it something to consider even if you don't need a truck to deliver pizza.

Popularity is also feature.

SVN

Works great for individual developers and small teams. It has more practical mechanisms in flows of simple work and that do not usually have much conflict. It shines when more control is required, especially in corporate environments.

If we do not consider the popularity, SVN should be the first choice of developers until one realizes a specific need that only Git can bring (and this exists a lot).

Advantages

• it is easier to learn and use and fits more into the intuition of programmers.
• behaves more like a version control of files in general.
• a single canonical repository is more suited to corporate philosophy allowing greater control and facilitating administration.
• allows you to work with parts of the repository. Allows mounting changesets.
• backup is very simple.
• allows you to lock files preventing updates.
• uses sequential version number that simplifies navigating versions.
• control of more sophisticated access privileges.
• easier to work with binary files, especially large ones.
• works best with renamed files.
• preserves the timestamp of the* files (at least in some situations).
• gives more freedom in how to work and organize the project.
• branches are just a part of the repository (for good or for good). evil).
• since it only works with the files, an initial copy of the repository is relatively fast.
• disincentives many complex workflows (yes, this is an advantage).
• is more mature, especially in Windows and use with GUI(it was an advantage, today no more, Giut has improved too much in this).

See more about some concepts that are strongly rooted in SVN.

SVK

Is it possible to adopt a more decentralized workflow with SVN through the SVK . At least some of the disadvantages of SVN can be mitigated in this way without losing most of the advantages. Too bad he is not actively developed. But regardless of this some people develop similar flows.

Git

A decentralized system shines when development is decentralized (I still don't understand individual use but I'm trying to understand ), especially in large teams with lots of updates and complicated flows. Of course it can be used in other environments as well.

There is a big learning curve. It has a philosophy closer to that of UNIX-based systems full of scattered tools and they are not so well documented, they are not thought to facilitate the work and understanding of what is being done, it is not very intuitive. (Beware, people who have been using it for a long time will say that the SVN that it's not intuitive. Yes, when you get used to a way of doing it becomes more intuitive for you. After it gets used to a job it becomes intuitive).

An important difference is that on distributed systems there is a distinction between commit and push . The commit creates a snapshot local and only push actually sends pending revisions to another (possibly remote) repository. In systems centralized commit does everything. This is simpler but creates difficulties in environments of many updates by different users.

Advantages

• controls content more generally.
• in almost everything runs faster, in some cases absurdly faster. It is optimized to work over the internet.
• the repository takes up less space. And it's easier to repair it.
• it is much easier to manage several sources of updates.
• it is easy to work with local copies to do parallel experiments and developments. branches are cheap and simple. They are even encouraged.
• encourages frequent commit.
• makes it very easy to do merge.
• allows you to work comfortably without losing any functionality and information without being connected to the central server (which can and often is used). He has more local metadata.
• has more audit information and that allows more facilities throughout the administration.
• handles end-of-line conversion more easily.
• revisions are digitally signed.
• the project history can be modified.
• has a staging area that allows you to select parts that you want to send to a repository.
• allows for a wider range of work.

Some of these advantages are available today also in SVN.

About centralized repositories do not scale well

This is not quite true, as I always say, depends on who does. Google made a single repository work well for its entire codebase and it is one of the largest in the world, absurdly larger than Linux which is understood that centralized would not work (of course they are different goals).

Also I always say that there is a difference between good programmers and good engineers. Who knows how to do engineering always finds better solutions. Who is not an engineer, and no harm in it, does what everyone is doing, sometimes thinking a little, sometimes without thinking. And don't get me wrong, these people are good at programming, they reasonably understand what they are doing, but they are looking for the ready solution and not the best solution. Although it has its merit, this is not Engineering.

Git is great, but I only use it because it's easier to use what everyone is using. If I were to choose a decentralized version control would be the Mercurial, but a centralized one usually suits me better. Everyone should look for what suits him best.

Conclusion

This analysis may be lagged because the two software try to get closer to each other and improve on their shortcomings (in fact this has been happening since I wrote the original version)). There is no miracle, the the only way to know for sure if the software is good for you is to install and start using it.