Should I look at version control systems beyond Subversion?

Question

Within the last year I have become addicted to subversion. I am an only developer and I also work on a few of my own projects. With SVN its really easy to manage everything - and because it is hosted on an online server though HTTPS I can access my code from anywhere. It is also great for deploying code to our production/development servers.

My point is that it does everything that I need it to do and has never failed me.

My question is that is there anything better? Am I missing some feature in another product that I could be using to make my life easier? I am always all about using the best software out there and have no problem migrating to new technologies.

I have heard of GIT and have done some research. I plan on giving that a try but while I am messing with that, are there another other source control systems that are considered "industry standard" and do they do things better then SVN?

Sorry if this is a duplicate question; but I did search beforehand.

Answer 1

I personally would stay with Subversion. From a professional stand point I have seen a lot more jobs ask for (and know) what Subversion was compared to GIT. Also there are a lot of open source and freeware tools built around Subversion, not to mention Subversion's huge community.

Source control is not always about the latest and greatest, but is more often about what is tried and true.

Answer 2

Git, Mercurial and Bazaar are distributed control systems that operate of the idea that you aren't always connected to the Net, and that there need not be one central version of the repository.

If you're doing a lot of detached work, sometimes called "airplane mode", as in you're on an airplane and can't commit, take a look at Bazaar. I've found it easier to acclimate to than Git or Mercurial.

If you're always doing work connected to the Net, and you're the only developer, then you can probably stick with Subversion.

Also, please consider the value of keeping your home directory in Subversion.

Answer 3

Here are 3 reasons to switch to git from Subversion (from MarkMcB):

• Endless, easy, non-file-system-based, local branches
• Stashing temporary work
• Collaboration before public commits

(Read the linked article for full explanations and direct comparisons of how to do the three things in both git and Subversion.)

Answer 4

Mercurial is also worth consideration; branching is much friendlier, and it can work without a network connection. I never seriously tried separating work into branches until I moved from SVN to Mercurial.

The one thing I seriously miss is TortoiseSVN; there's a workalike (TortoiseHg) that's pretty good, but it's just not the same..

Anyway, creating a Mercurial repo from an SVN one is trivially easy...give it a try and see whether it suits you or not.

Answer 5

I also personally would stay with Subversion, Is there anything better?

Subversion is a great version control system, and you're happy with it, so if you are looking further, I can recommend you to get some info about Continuous Integration, there are many tools out there that can help you to make automatic builds, make your builds self-testing, check the integrity of each commit, and much more...

Answer 6

The best reason to change is necessity. However, it sounds like there is no real need to change. You are an "Army of One" so most of the powerful features do not apply to your situation. Yes, people will argue with me on this, however they will be pushing this feature or that feature which more than likely you really do not need. Timing is everything, if in the future your needs change then change your solution.

There will always be better or different solutions for a problem space, in this case source control, however you should balance personal development, process/practice improvements, and delivering work product. You could learn more about the different solutions/applications for source control to expand your knowledge to recognize when it is time to switch solutions but stick with what works for now.

Answer 7

Hi there,

Mercurial

I mainly used CVS and SVN, happy and content, then I started researching Distributed Source control as there was lots of fuss made about DSVC. After a using DSVC I noticed a change in my development style, I became more fluid and adaptable. Allowing me to merge back into trunk or experimental branch painlessly.

• Mercurial can scale from a one man band to huge ie OpenJDK, without much headache.
• Mercurial is fast, maybe not as fast as GIT, but it is still really quick
• Mercurial Queues is a fantastic way of managing patches. At the speed of greased lighting.
• It can run on different OSes, compatibility is great as it is based on python.
• the learning curve is lower than GIT, after a few docs read you get the basic jist of things (http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/)
• hg allows (so do many DSVCs) you to interface with a corporate SVN Source control with hg-svn and hgsubversion which is a wonderful extension with allows and checkouts, but not yet pushing or commit functionality
• You may also setup a HTTP server run push and pull via SSH
• also have really neat option of getting together with your coding buddies and simply startup HTTP server run it over localhost and your mates can push and pull while you doing a code sprint.
• You may also see the current status of the project via this HTTP page.
• lastly look here for a brief description of the simple commands (http://edong.net/2008v1/docs/dongwoo-Hg-PDF.pdf)

Git

• tried it, its support for svn is better than mercurial. but since hgsubversion is on the up and becoming competition for git svn.

Git is cool, but you need to constantly maintain your source code depo and repack it. As it consists of many bash scripts it has trouble running on windows. But it is blazingly fast, with many features for you to use. Actually the amount of features can be a disadvantage.

BZR

• never tried it

I havnt looked back since I started with HG

Answer 8

Rule no. 1: "Never change a running system"

Also, as there are many shiny new solutions(for problems you do not have, as you work alone) you should consider the cost of switching to a new VCS: The import of subversion to mecurial/git is not an easy task

there is no tool (AFAIK), which imports svn repos by using the dumpformat. So if you do not use the dumpformat you will stick to checkout all branches/tags from svn and adding them to git/BZR/mecurial manually/via script

So I do not know how big your repos are(my repos are ranging from 20 MB to 24GB), but it will take a long time to check out a whole repo and even small projects with lot of tags will eat up a lot of harddisk space.

Additional problem is the time until your migration is done you cannot continue to work.

Answer 9

If SVN addresses all of your needs then I don't see the reason for change. If curiosity is the driver of your quest for a different source control then I would recommend reading about git or other distributed scm solution and try to figure out if it's worth the investment in order to switch (which i doubt it is in your situation).

Answer 10

There's an old Yankee proverb.

If it ain't broke, don't fix it.

Answer 11

I am just like you in the issue of constant investigating in order to get the best tool.

I tried SVN for SOLO work and someone recommended me Mercurial (hg). Now i do keynotes about it. It's more friendly than git in windows. I now i think "why do svn complicates with simple task like tags". SVN doesn't know what a tag is. For SVN a tag is a copy. In mercurial a tag is an alias for a revision. How complicated could it be?

Performance it's an other issue. In Mercurial your repo it's in your local machine. So it's very fast for a log, or diff or history.

Although I do not know anything about servers that support mercurial for a online version of your repo.

Answer 12

It's definitely worth looking into "distributed" VC even if you're not actually using a distributed workflow. Being able to have private branches and control over your local commits is worth the effort of learning git. I've been mainly using git-svn (with other team members using regular SVN clients, so we had a normal, centralized workflow), and it worked pretty flawless.