2020 Version Control Software Comparison: SVN, Git, Mercurial

version control software

Is your next big business idea is based on software development? Does it involve an elaborate technical concept, or simply requires a large distributed team working on one task? Then you need to learn two words by heart: Version Control.

Version control, also called subversion control, or revision control, helps large projects from spinning out of control by letting individual programmers, writers, or project managers tackle a project from different angles without getting in each other’s way and without doing damage that can’t be undone.

There’s a great visual introduction to version control here if you are completely unfamiliar with the concept.

See how Time Doctor’s easy-to-use time tracking software can help your team be more productive.


If you prefer a video explanation, check this one from GitHub instead:

So, which version control is right for your project?

There are a number of solutions out there, and so we’ve put together a definitive feature comparison so you can decide the best solution for you.

This is a fairly technical topic, so if you don’t have a software background, read our comparison carefully, and consult with your lead technical personnel before you make any final decisions.

Version control software, including the well known SVN and Git, was designed from the ground up to allow teams of programmers to work on a project together without wasting man-hours on paperwork. Instead of manually scanning branches of code and associated notes, version control allows for a central repository that is organized, logical, and facilitates file updates, notation, and even merging.

There are a lot of opinions regarding which version control framework is the best, and can force programmers and project management teams into fierce debate. When choosing the right version control for your project, you should consider that some of pros of one package you will come across are subjective, meaning the opinion of the programmer, and other factors, such as speed and IDE plug-in capabilities, overshadow the raw numbers.

The main difference between version control systems is whether they are server based or peer-to-peer. Either they have a centralized repository where code is checked out and back in with changes, or a setup where the code is frequently updated from peer sources, a more decentralized network, to keep code current.


Beyond that, you will also want to consider speed, functionality, and the learning curve associated with the system. To decide which one is right for your project and team, let’s take a look at some of the major systems available and the reasons why some programmers prefer one over the other.

Concurrent Versions System (CVS)

CVS has been around since the 80s, and has been very popular with both commercial and open source developers.

It is released under the GNU license, and uses a system to let users “check out” the code they are going to work on and “check in” their changes.

Originally, CVS handled conflicts between two programmers by only allowing for the latest version of the code to be worked on and updated. As such, it was a first come, first serve system where the user must publish changes quickly to ensure that other users haven’t beat them to the punch.

Now, CVS can handle branching projects so the developed software can diverge into different products with unique features and will be reconciled at a later time.

The CVS server runs on Unix-like systems with client software that runs on multiple operating systems. It is considered the most mature version control system because it has been developed for such a long time and does not receive many requests for new features at this time.

A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality.


  • Has been in use for many years and is considered mature technology


  • Moving or renaming files does not include a version update
  • Security risks from symbolic links to files
  • No atomic operation support, leading to source corruption
  • Branch operations are expensive as it is not designed for long-term branching

Apache Subversion (SVN)

Apache Subversion

SVN was created as an alternative to CVS that would fix some bugs in the CVS system while maintaining high compatibility with it.

Like CVS, SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU.

To prevent corruption in the database from being corrupted, SVN employs a concept called atomic operations. Either all of the changes made to the source are applied or none are applied, meaning that no partial changes will break the original source.

Many developers have switched to SVN as it is a newer technology that takes the best features of CVS and improves upon them.

While CVS’s branch operations are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it, lending itself better to large, forked projects with many directions.

Criticism of SVN includes slower comparative speed and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model rather than using a centralized server to store code updates. While a peer-to-peer model would work better for world-wide, open source projects, it may not be ideal in other situations. The downside to a dedicated server approach is that when the server is down, no clients are able to access the code.


  • Newer system based on CVS
  • Includes atomic operations
  • Cheaper branch operations
  • Wide variety of plug-ins for IDEs
  • Does not use peer-to-peer model


  • Still contains bugs relating to renaming files and directories
  • Insufficient repository management commands
  • Slower comparative speed


Git version control software

First developed by Linus Torvalds of Linux fame, Git takes a radical approach that differs greatly from CVS and SVN.

The original concepts for Git were to make a faster, distributed revision control system that would openly defy conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there.

It will also run on other Unix-like systems, and native ports of Git are available for Windows as msysgit.

As there is no centralized server, Git does not lend itself to single developer projects or small teams as the code may not necessarily be available when using a non-repository computer. Workarounds exist for this problem, and some see Git’s improved speed as a decent tradeoff for the hassle.

Git also comes equipped with a wide variety of tools to help users navigate the history system. Each instance of the source contains the entire history tree, which can be useful when developing without an internet connection.


  • Great for those who hate CVS/SVN
  • Dramatic increase in operation speed
  • Cheap branch operations
  • Full history tree available offline
  • Distributed, peer-to-peer model


  • Learning curve for those used to SVN
  • Not optimal for single developers
  • Limited Windows support compared to Linux


Mercurial version control software

Mercurial began close to the same time as Git and is also a distributed revision control tool.

It was originally made to compete with Git for Linux kernel development, and as Git was selected, Mercurial has seen less success in that area. However, that is not to say that it is not used as many major developments use it, including OpenOffice.org.

It’s different from other revision control systems in that Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used.

Due to its distributed nature and its creation in Python, the Python language developers are considering a switch to Mercurial as it would allow non-core developers to have easier access to creating new trees and reverting changes.

Users have noted that Mercurial shares some features with SVN as well as being a distributed system, and because of the similarities, the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial also is more complete and will facilitate learning the differences faster.

Some of the major drawbacks to Mercurial include that it doesn’t allow for two parents to be merged and unlike Git, it uses an extension system rather than being scriptable. That may be ideal for some programmers, but many find the power of Git to be a feature they don’t want to trade off.


  • Easier to learn than Git
  • Better documentation
  • Distributed model


  • No merging of two parents
  • Extension-based rather than scriptability
  • Less out of the box power

Which system should I use?

Version control software for programmers and developers

For the most part, people use CVS because they are already used to it, and while some of the quirks and limitations are bothersome, they’ve already figured out how to make a work around the given limitations and have those workarounds implemented. Especially if your team is currently engaged on a certain project, the prospect of migrating everything to another revision control is annoying, and if they were to switch, it would most likely be to SVN.

As it has now moved into the “mature technology” part of its life cycle, it is unlikely that CVS will come out with any groundbreaking features, and as momentum is lost in the project as people move to SVN, it appears most likely it is on its way out.

SVN is currently the king of server-based version control. It has all of the good features of CVS and improves upon them. In terms of corporate interaction, you are more likely to come across CVS or SVN than you will with Git or Mercurial, so a familiarity with single server technology, while not a requirement, will ease the transitions in the workplace.

With its wide range of usage and its software maturity level, SVN has a large knowledge base, and users will be able to find help readily accessible from other users.

Git has a clear speed improvement over its competitors, and for projects that lend themselves to distributed systems, it is a clear improvement.

The primary downside cited for Git is that it can be at times difficult to explain to others, and there is likely to be a slow down in production as programmers adapt to it. Once it is learned, however, the speed increases and better branch management will reclaim that time and more.

For those absolutely repulsed by Git (and it does have its sworn enemies in the programming world), Mercurial offers a bridge between SVN and Git that is well documented and used in many well known projects.

The Windows-friendly version of Git has also made some strides which brings the speed closer to that of the Linux versions, so it could still be on the table if you are not developing in Linux.

To find out which one is best for you, consider the project and the developers. And talk to them!

If you want to have a single master source tree that is being worked on by a small core development group, SVN should be the first system you try as it’s reliable and tailored for that.

If you are starting an open source project where several programmers are going to be working at different times and/or submitting several updates to the code, Git is an excellent choice for your project due to the huge speed boost and improved tree management over SVN.

If you’re somewhere in the middle or you just really don’t like the way SVN or Git works for you after trying them, there’s always Mercurial.

All of these systems are fully functional. They’re also all free. They’ve all been used to create software, websites, and even operating systems that you’ve used and heard of.

The first decision you will need to make is whether the choice fit the needs of your business and team, and then—just as important—you should make sure your choice isn’t going to send your coding team into a rage.

Getting Started with SVN

If you’ve never worked with SVN or GIT before, and wouldn’t have a clue where to start, a hosted solution coupled with a graphical desktop client means you can be up and running in no time.

Like most things, you’ll learn your way around more quickly by jumping in and trying things out – Using Subversion is very similar to working with files from your host using an FTP client. If you’ve never done that before, perhaps try that first.

NOTE: I wouldn’t have a clue how to set up subversion hosting, there are plenty of great hosted options around, some with free trials so you can create your very first repository (the place where you’ll collaborate on files) at no cost. Here are some options to check out.

SVN & GIT Hosting

  • Beanstalk git and subversion hosting


    – Secure, private and reliable Git and Subversion hosting. View activity, browse files, compare revisions. Great user interface. Integrates with a bunch of popular services, including Twitter! From $15 a month

  • Unfuddle subversion and git hosting


    – popular subversion and git hosting and hosted project management solution for software development teams. Comes with a handy Widget for Mac OS – you can monitor account activity across all of your projects from one simple interface. Free with 2 people, with 1 project for up to 200MB storage

  • SlikSVN subversion hosting


    – another option for free hosting, but not as good as Unfuddle, subscriptions are competitive. Free with 1 person, with 1 project for up to 100MB storage

  • XP-Dev.com


    – Subversion, GIT and Mercurial hosting. A decent feature set and represent excellent value for money. From $5 a month with unlimited projects, users and up to 2GB of storage

Creating your first repository

Once you’ve created an account, you will need to create a repository – different on each platform. Typically you’d do something like this:

  • Once logged in, click on your projects
  • Create a project:
    • Under Create a New Project enter a name for your project.
    • Click on the Create Project button
  • Enable Subversion:
    • Once your project is created, click on the Source Control tab
    • Click on the link Enable Source Control
    • Give your Subversion repository a name.
    • Click on the Save button

Graphical Clients for SVN and GIT

You’ve got your repository setup, and if you want a simple way to access it, a graphical interface is your best option.

  • TortoiseSVN subversion client


    – an easy to use source control software for Microsoft Windows and possibly the best standalone Apache Subversion client there is. It is implemented as a Windows shell extension, which makes it integrate seamlessly with explorer. It’s also open source with around 34 language packs available

  • SmartGit Git client


    – a graphical client for Git, an Open Source distributed version control system. It runs on Windows, Mac OS X and Linux. $59/year.

  • Versions Mac Subversion client


    – SVN client for MAC OS X – Versions offers the simplest Subversion on the Mac. In their own words, “Thanks to its clear-cut approach, you’ll hit the ground running”. It is easy to use. $39 GBP (around $64 USD at today’s exchange rates).

  • Tower Git Client for Mac


    – GIT client for MAC OS X – is another very elegant solution, and is perfect for GIT users who have no need to learn command line syntax.  There’s also a good introductory overview on their product tour which covers a lot of the basic GIT concepts (see below). $69/user/year.

“Checkout” your repository

In whatever client you are using, you need to create a new source control repository. You will need to enter the URL of you repository along with your user name and password in your client.

The URL will typically look something like: https://svn<server number>.hostname.com/svn/<repository>
(you can use https:// (SSL) if you have a paid account)

  1. click on the root folder, then click on the Check Out but­ton and cre­ate a work­ing folder in the client. You can now add files to this folder.
  2. After check­ing out the project files, you can edit them from the directory you’ve created on your local computer

After edit­ing files, to commit them, click the check In but­ton in the tool­bar to update the changes. You can review the changes and add a com­ment – it’s a good idea to add comments so you can remember what you were work­ing on, what changes you made, and to notify other members of your project what you’ve been up to.

In your client you should also be able to check revisions at any time by click­ing on the revision viewer or history button – you can then restore previous changes, for each file if necessary. Once you have your head around these basic concepts, the documentation provided with each client is a good starting point for more advanced features.

All of these systems are fully functional. They’re also all free. They’ve all been used to create software, websites, plugins and themes, coding frameworks, mobile and web applications and even fully-fledged operating systems that you’ve used and heard of.

Besides the ability to back up your code safely in the cloud, allowing your developers to work from anywhere, version control can also allow you to find and revert changes which might have broken your regression tests. By performing a diff between the current and previous versions, you can easily determine what has changes were made and then rectify as necessary.

Try Time Doctor Free for 14 days

Get more stuff like this
In your Inbox

Subscribe to our mailing list and get interesting stuff on remote working and productivity to your email inbox.

We respect your privacy and take protecting it seriously.


  • Avatar Vikas says:

    If you are using Visual Studio, inbuilt Git software works best rather than using SVN, Tortoise Git etc.
    Also it is easier to use.

  • Avatar Shayne says:

    Uh Mercurial less powerful than Git? I dont think so!.
    Gits features are a SUBSET of Mercurial. While Mercurial with a Git plugin can support *all* features of Git, Git with a mercurial plugin can’t support all of mercurials features, because there aren’t equivelents.

    The only real downsides are: Its a bit slower than Git (Gits a rocket ship, theres no denying that), and it just doesnt have the marketshare it used to have (Boo Atlassian!). Unfortunately that last point is why I’ve *very reluctantly* moved to Git. Atlasian’s vandalism of Bitbucket gave me no choice in the matter.

  • Avatar cyp says:

    Git is the worst versioning system. You listed what it promises not what it delivers. Git often fails at doing simple merge or branch switch due to many branches is extremely sliw and occupies lot of space and its over complicated procedures make you often lose an entire day for an operation that should be done in 15 min. Is awful. Even VSS is better.

  • Avatar Paul says:

    Here, you’re welcome. I fixed the pros and cons lists for you for the relevant VCSs:

    == Git ==
    Great for those who hate CVS/SVN (and love dozens of inconsistent command line tools masquerading as a single one that sticks the user the finger; nomen est omen)
    Dramatic increase in operation speed (compared to CVS/SVN, but not compared to Hg)
    Cheap branch operations (local only, anything else is cumbersome and requires good shell foo)
    Full history tree available offline (except for the parts that have been garbage-collected or rebased away by following cargo-cult recommendations of How Things Ought To Be Done With Git™)
    Distributed, peer-to-peer model (almost, except for some pretty basic operations like cloning local repo to remote one in a single step)
    Learning curve for those used to SVN (and generally anyone not used to Git or familiar with the secret glossary of Git-only terminology)
    Not optimal for single developers (or anyone who believes that a VCS should help them get their job done and isn’t a masochist)
    Limited Windows support compared to Linux (not so much with Git for Windows, although speed is still an issue)

    == Mercurial ==

    Easier to learn than Git (and just as powerful)
    Better documentation (with actual help output when you ask it)
    Distributed model
    No merging of two parents (uhm, so what am I merging when I merge? two … uhm … what do you call them? even the Hg documentation calls them parents [or sides] … and it just doesn’t support *more* than two)
    Extension-based rather than scriptability (wait, why did this end up as a con?)
    Less out of the box power (wrong, less default-configured chances to shoot off your legs)

    I am not going to hide that I am biased in favor of Mercurial. Because it has a design, it has a concept and – for the most part – is a consistent tool that helps me get my job done. As opposed to Git which does honor to its name and does quite the opposite.

    SVN is kind of okay, but it gets sluggish quickly and it mixes concepts that should not be mixed (such as paths and tags/branches). If you ever made a serious VCS conversion effort, you’ll know what I mean. However, the one thing that SVN did that sets it apart from CVS is an overbearing repository-wide revision number. Big deal, if you ever had to dabble with CVS and the multitude of RCS files on the server.

  • Avatar Wellerson says:

    Hello, great article. IMHO I’d like to suggest that you change the title to include CVS in it. The title brings three tools and you talk about four. I personally almost skipped your site in search result as I couldn’t see CVS in it.

    Thanks again for the clean text.

  • Avatar Ilmari Kontulainen says:

    Thank you for the great article. I would like to add Deveo to the tools list as it supports Git, Subversion (SVN) and Mercurial (HG). The pricing is lower than most of the tools listed and when you see the product you quickly understand what a good user experience means.

  • Avatar Abhijit Sarkar says:

    Should’ve stopped reading when I saw this as a pro for Git:
    Great for those who hate CVS/SVN

    Now it’s too late.

  • Avatar Patrick Reynolds says:

    This probably needs to be changed to something like “To prevent data in the database from being corrupted, “

  • Avatar michael says:

    If there is one thing I wish SVN would adopt from CVS, and where it makes release mangement harder than it needs to be, it would be to simplify the task of tagging a release set when grabbing specific versions of a set of files from the trunk instead of it’s default of grabbing across the tree based on a single, global commit point.

  • Avatar TS says:

    I’ve abandoned CVS for being too obsolete to handle renaming or moving or deleting of files and folders. Any of the others is a better choice.

    Subversion is the one choice that lets you control control access over who is able to do what to which sub trees. For example, in a classroom environment or secure environment where people should not see each other’s work, SVN is necessary.

    Mercurial works a lot like subversion for people working alone. When you are disconnected from the net (perhaps on a long flight) you can still commit code when you want to. I haven’t tried them, but there are supposed to be tools (most notably HgSubversion) to allow you to work disconnected with Mercurial and then merge all your changes to the server as you push. I’ve not tried it, but it sounds like the ultimate setup.

    Git is a low level tool that could be made useable with wrappers around it to suit your developmemt process. Unless you know its internals, feedback when something goes wrong (conflicts needing to be resolved, for example) can be totally and inexcusably misleading. Subversion and Mercurial either make assumptions that you’re following some standard usage practices, or enforce them, so they are better at directing helping the user know what to do next. If your team already uses and prefers Git, go for it. Anyone else would benefit from something more structured.

    Then there’s Bazaar. I haven’t done enough with it to tell of any advantages or disadvantages beyond saying that it’s currently not popular.

  • Avatar John King says:

    Pros for GIT: “Great for those who hate CVS/SVN” – seriously?

  • Avatar Danny says:

    Thank you for the great mention of Unfuddle. Very much appreciated, and we would be thrilled to answer any questions from you or your readers. Thanks again!


  • Avatar JP says:

    Try Kiln from Fog Creek Software (fogcreek.com/kiln). It’s free for 2 users and supports Git and Mercurial.

  • Avatar Jerker Montelius says:

    If you have binary data(.jpg .gif .wav .dwg .doc) in your project SVN is the only modern system hadeling that case.

  • Avatar anthropomorphic says:

    Why is GitHub not listed in the “SVN & Git Hosting” area? GitHub is immensely popular, and in my experience it is the most pleasant/featureful/easy-to-use Git host out there.

    • Avatar Zahid says:

      Does Git allow one to many configuration? For example, one server hosts all the repository and different PCs can access it to either check in/check out a file/project. I am using TFS: Source Control but it requires you to upload a solution and download the entire solution not just an individual file.

  • Avatar Obfuscator says:

    Can anyone explain the “merge two master repositories” thing, please?
    As a starter, this is what I understood to be the problem:

    DevA@MachineX does hg init and starts adding stuff
    DevB@MachineY does hg init and starts adding stuff

    At some point the two want to combine what they did in a single repository.
    Is that the problem mentioned above? What is the workflow to get this done in mercurial and/or git? Will the revision logs/version numbers etc. then be merged as well or will it simply be a new repository starting from scratch?

  • Avatar Debbra says:

    Getting to the top, especially if the amount of competition for your
    specific keywords is high, you might want to focus on other techniques to
    help you in the interim and that will also assist you with your rankings, such as link building.
    Google may consider the so-called anchor text within the link (the word
    or phrase which is linked) and the authority of the website that the link is coming from to determine how highly
    or lowly your website ought to rank. For instance,
    if you write about flooring, you might have carpet ads on your page.

  • Avatar mtemanuel says:

    I have selected Git for my team but I like the analysis presented. Except for the bias of of the use of “man-hours” which would be much better presented as “staff-hours” since I am hoping that your staff is inclusive and that it was just an oversight.

  • Avatar KGarvin says:

    I have a small development team that works on many different projects using different apps with different filetypes, including Microsoft Dynamics SL, Crystal Reports, Visual Cut, Access, and lots of documents and images, etc. Half of the team works remotely, and finds connecting over the VPN pretty slow. Right now we have five testing machines and a live sever that all mirror most of the same environments, and use our own machines to host code and deploy to all of the different servers. Messy. We have Windows servers. We want a way to keep the code organized and be able to develop and deploy to many locations, keeping track of which machines the fixes were deployed to, and also to be able to work on files and then save/merge changes in a shared location for all to access. Keeping track of versions and history is key, and it would be nice to have the option to lock out other developers from files if necessary, and also to save a change or a bug fix as a unit of files, for ease of deployment. What say you?

  • Avatar PFury67 says:

    Hard to disagree with Tim Eckel more. I don’t want to focus on versioning things myself, akin to how I don’t want to make a logging module from scratch.

    Setting up GIT and learning a few commands is not a hard thing. The project can grow without having to constantly develop a system to maintain code versioning.

  • Avatar Tim Eckel says:

    Why not list the other option, no version control system at all? I’ve done everything this way for 30 years and have never had a problem. I create my own versioning backup system and via the cloud update all my development systems in real time. The advantage is that everything is automated and runs in the background. There’s nothing to ever do, no CLI commands to issue, I can just focus on development from any system and everything is always up to date. If I ever need to go back (which is SUPER rare), I can easily go back to my archived version database and retrieve what I need.

    I can honestly not think of a reason why I would use any of the version control platforms listed in this article. I’ve tried using them, and they all get in the way of development.

    Spend more time developing and less time messing with typing in CLI commands (how 80’s). Maybe when the version control systems are updated to work like software from this century I’ll reconsider.

    • Avatar LaPingvino says:

      Then look at Sparkleshare. It works like Dropbox, using Git under the cover. You won’t ever have to check in manually.

    • Avatar Zangdaarr says:

      If you can allow working without an SCM, it’s probably because you are working alone, without a team doing parallel development in the same files, in separate branch.

      In our case, we are using Hg and we would not be able to work without it (or Git, it does the same stuff). We are constantly merging branches and clones, and our merges often imply more than 900 files. Some are trying with SVN (or worst), and they spend weeks doing merges.

      Even alone, I do use Hg, it allows me to work in branche, separate my change efficiently, work on parallel tasks and then merge it easily. It also makes me save a lot of time because I can find traces of change I made months ago very quickly and take actions if needed.

      I would not switch it for SVN, ever, which as you said is often a loss of time, and I will not switch to a non controlled version system.

    • Avatar jay says:

      When I was playing with stuff at home — like I have a little program to print calendars, another to manage my checkbook, etc — my “version control” used to be that I made a backup copy of the entire source. But now I use SVN. Even for a single user working on tiny projects, it has distinct advantages. It keeps the entire history of the project, not just one or two previous versions. It keeps log messages with every updates so I can go back and see what I did. If I see a problem, I can easily compare to earlier versions to see where the bug was introduced. Etc. I rarely create branches at home because I’m the only person working on the code and my requirements are modest, but I’ve had a couple of times that I created a branch for an experimental change. When it worked out, I merged it back into trunk. When it didn’t, I just abandoned the branch.

      I find it adds very little effort to use. I use the Tortoise UI so committing a change is just a matter of right-clicking on the directory, click “SVN Commit”, and type in a comment. That’s no more work than copying a directory.

  • Avatar Harry Gilmore says:

    “If you want to have a single master source tree that is being worked on by a small core development group, SVN should be the first system you try as it’s reliable and tailored for that.”

    This is crazy. SVN has no significant advantages over Hg or Git, regardless of team size. If you want a “single master source tree”, then set up a single master Hg/Git server for your team to use (instead of a single master SVN server).

    As SVN relies on the network for so many basic operations, it’s going to be slower and less reliable, in addition to merges being much more difficult.

    Advocating SVN — or, heaven forbid, CVS — after about 2008 (3 years was plenty of time to shake out the early issues with DVCSs) is irresponsible. Non-distributed VCs like CVS are “mature” in the same way that Windows 3.1 is “mature”: seriously outdated, and due to their ancient architecture, simply unable to add the modern features that users today can reasonably expect.

    If your VCS needs to do an O(n) set of queries over the network just to show annotations for a file, it’s not suitable for use. That was barely acceptable in 1990 when we wanted backwards compatibility with RCS, but there’s no excuse for it today.

  • Avatar Sello says:

    subversion is awesome when used with netbeans.

  • Avatar Subversion Download says:

    Thanks. There are a number of solutions out there, and you need to do definitive feature comparison so you can decide the best solution that is best for you.

    • Avatar Lokiitoo says:

      I use Git both at work and for personal rjepocts. Its superior branch merging and local branching capability are great advantages over Subversion. Git is very powerful but as a result has lots and lots of commands, options and features that are confusing and unnecessary for everyday use. However I found that once you learn how to do the basics, you can get by perfectly fine. My advice would be to seek out a friendly tutorial and avoid the official documentation as a learning resource it’s just confusing!

  • Avatar Afriza N. Arief says:

    100% agree with Ches Martin.

    In addition, mercurial allows users to specify the format for its output ( http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html ), so it’s actually scriptable and there are even more options to make script: by using APIs or using exec-approach.

    The scriptability nature of git is one of the reason there are efforts to make cleaner API-based implementation like libgit2 (initiated by GitHub employee, https://github.com/blog/752-libgit2-a-git-linkable-library )

    And it’s super easy to use mercurial or git as a single developer. There is absolutely no need to set up server or such a thing.

    “doesn’t allow for two parents to be merged” – are you talking about some other version controls? it’s definitely not mercurial.

    “Less out of the box power” <- this is actually for users' own safety. Possibly "destructive" features (or "destructive power" as you call it) are not turned on by default so that no data is lost by default.

  • Avatar John says:

    Ches, thanks for corrections!

  • Avatar Ches Martin says:

    > “As there is no centralized server, Git does not lend itself to single developer projects or small teams as the code may not necessarily be available when using a non-repository computer.”

    I don’t understand this either. As a single developer, if I want to use SVN I need to configure and run a server (svnserve). With Git, `mkdir newproject && cd newproject && git init .` — done. Start working.

    I think you’re confusing concepts here. Distributed systems *allow* you to work completely offline, whereas earlier systems prevent or encumber this (with SVN for instance I can edit my code offline, but can’t commit the changes, so it’s troublesome to work on multiple different features and keep changes organized).

    The scope of this article is ambitious, but it needs more research and editing I’m afraid.

  • Avatar Ches Martin says:

    I’m not sure what you’re trying to say with Mercurial “doesn’t allow for two parents to be merged” — that’s absurd, of course it does. It’s a distributed version system, as such making branching and merging less painful than SVN is inherent to its design.

    Also, in regard to “it uses an extension system,” the continuation “rather than being scriptable” doesn’t logically follow. Mercurial exposes a clean public Python API, thus many features in Mercurial are moved out to optional extensions in order to keep the core set of commands clean. This lends to its learning curve being easier than Git’s. I’m not aware of any particular strengths for Git in the scripting department — you either dig into its hairy C and shell code to try to extend it, wrap the usual command line calls in your own scripts, or use libraries that wrap it or fully re-implement parts of Git like Python’s GitPython, Dulwich or Ruby’s Grit. If you’re scripting the command line interface, I don’t see why that should be any harder for Mercurial than Git.

    I’m not intending to take a stance of arguing for Mercurial as the leader in this argument — I use Git more these days — but I do think this assessment of Hg is inaccurate and somewhat unfair.

  • Avatar hardwyrd says:

    On Linux, there’s actually RapidSVN. I use it on my Ubuntu 10.04 64bit and on my Fedora boxen.

    However, some purists actually shy away from gui-fied SVN clients and use the terminal client instead since it offers much more scripting flexibility and what not.

  • Avatar Tantrido says:

    Not necessary to talk about CVS, I think, it is a dinosaur. One of its big disadvantage – it does not allow to version folders (directories).

    We’re using subversion now. Good enough for small teams. However there is not enough good clients for it: TortoiseSVN is good enough, kdesvn + kdiff3 (or kompare) in Linux – good enough too, however there is not good open source (or free) client for Mac. Latest XCode 4.1 has a svn client, but seems it is not ready and not stable.

    Very interesting to try git, to learn something new and because it better work with branches as people say. Also it has good clients for all platforms. Also I like that it stores meta information only in root folder, unlike svn has .svn subdirectories in every project directory – sometimes it is not very convenient. Also it is very good that git is faster – critical for big projects.

    Also need to mention following clients:
    TortoiseGit – open source client for Windows.
    SmartGit – commercial

Leave a Reply

Your email address will not be published. Required fields are marked *