Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 563
  • Last Modified:

What's your favorite Version Control System (VCS), and why?

Recently, a couple of other experts (I won't say who they I'll leave it up to then if they wish to 'fess up ) and I have been discussing which is our favourite/preferred VCS. I am an ex SubVersion user who finally saw the light and migrated myself (and my team where I work) over to Git and I have never looked back! I still on the odd occasion have to use SVN (we only migrated trunk and on the odd occasion we have to look at old branch code) and it makes me cringe!

Whilst I won't say this migration was a walk in the park it was also not that painful. Git comes with a tool that allows you to clone an SVN repo and it's pretty simple and quick. The most painful part was deciding to break our massive SVN repo into smaller Git repos; one for each project rather than all projects in one repo. This; however, was an internal design decision (it wasn't necessary just for the migration) and even if we'd not moved to Git we'd have eventually had to restructure our repo.

The nice thing about moving to lots of smaller repos are (a) I no longer have to have a mass of code on my laptop that I don't look after and (b) all our code is now fully de-coupled (we can no longer rely on things living in a specific place like we could in one monolithic repo), which means things are more robust -- although there was pain in getting to this point but it was worth the hassle.

I've never looked back since moving to Git. The workflow I get from using it is far superior (in my view) and flexible than that of SVN. Further, Git is just far simpler to use, more powerful (in terms of how cheap it is to branch and merge -- meaning I can experiment without the pain and fear of having to merge my changes (unlike with SVN).

Of course, there are also good arguments (this is where you come in!) for using a centralised VCS -- or, at least, this is what die-hard SVN/CVS/Other users firmly believe :)

So, I just wondered (and this is just for fun, so please no flaming wars!), which is your favourite VCS? Do you even use one? If not how to do manage version control? I'd especially be interested in hearing from anyone who is (forced into?) using Visual Source Safe; possibly the worse VCS ever -- I especially love the way it silently corrupts its contents, especially if you are pro using it :)

I look forward to your views... and I promise I won't let my own personal views cloud my decision when it comes to closing down and awarding points. What I'm after is some interesting and constructive discussion.

Thanks in advance for taking part :)
4 Solutions
evilrixSenior Software Engineer (Avast)Author Commented:
To kick off, this is what convinced me to look at Git as a serious alternative to SVN

Tech Talk: Linus Torvalds on git

That and the plethora of praise others in my team were pouring on it.
First of all, I prefer using DVCS to other forms of VCS, and I probably prefer Git above others (although I'm starting to develop a soft spot for Mecurial).

I don't necessarily agree with some of your points though.

I don't think that git imposes a workflow.  I think it's a set of tools that allow you to develop your own workflow.  And, in fact, the important step in adopting git is to decide on a workflow that suits.

And if the only argument against git is it doesn't have a centralised repository, then it's flexible enough to have a workflow that includes a master/central repository.  Look at the Linux git workflow.

And finally, is branching easier/cheaper in git?  Or is it just so fundamental to the operation of git that you learn how to do it much sooner?  I managed to use SVN type VCS for years before I had to branch.  I think I'd been using git for 5 minutes before it made me branch.
My personal story about using CVS first.  I have started my real project in August 1999 (resurrection of the dying project).  The colleague of mine joined me in February 2000.  (The dying version of the application was maintained in parallel, separately.) The first customer got the new version of the application in December 2001.  Until May 2002, we distributed the application to five customers.  The equivalent of the build number was about 260 (continuous numbering, closed when we agreed that the changes form something worth to be kept as separate.

Until then we kept the separate builds in separate subdirectories (like Prototype260) and we worked at separate locations, communicating via e-mail and phone.  We always had to agree first who will focus on what area to minimize conflicts.  No version control was used.  I was responsible for merging the files "manually" using the primitive ways of comparison first (the modification date, size of the file, diff tool via cygwin, calculating md5sum later, etc.).  I knew about existence of RCS and the later CVS; however, I did not have any working knowledge (nobody in the company had).  

In that time, it became apparent that I have to stop to be lazy and have to learn the CVS.  At the time, SVN was not the option for Windows.  It was not matured enough.  However, there was CVSNT available -- the derivation of the CVS, a bit enhanced, tailored for Windows.  I was a bit reluctant to use the "Microsoft only" solutions, and I had no good references to their revision control systems of that time.  I have heard about Visual Source Safe later, but we had already started with the CVSNT and I had no reason to switch.

The application was written for Windows, using the Visual Studio starting from version 6.0 (now Visual Studio 2008 and getting ready for VS 2010).  The project currently has about 250 thousands source lines (C++, configuration files...) plus about 23 thousands lines of documentation text sources.  

When introducing CVSNT in may 2002, I have prepared also some scripts to extract and zip the sources that should be sent to my colleague (and the same back from him).  We both actually keep our own local repositories on our local computers. The repository on my computer was chosen to be the reference one.  We still create branches based on mutual agreement.  We have developed some rules on how to name tags, etc.

To summarize my experience... I would consider unthinkable not to use any version control system now.  I fully agree with someone's "programming withou version control system is like jumping without parachute".  I strongly suggest to anyone to learn whatever version control system that seems to be good enough at first look.

Now about newer systems (SVN, Git, Mercurial).  In my opinion, if a small number of developers work on a bigger project for longer time, they need not to understand details of their version control systems.  They tend to use some subset of its functionality, and the newcommers learn from the seniors.  My guess that majority of programmers do not have a formal education in Computer Science (university level).  Because of that they often do not have a big picture of the project infrastructure (the reasons why the things are done this and that way, using the tools,...), and they do not see the alternatives.  They are just happy with what they have.  The senior programmers may wish internally to introduce some newer tools, but they are a bit more lazy and less enthusiastic (as people in any other kind of job).  They also tend to behave more "economicaly".  Because of that it may seem that they are against the changes.

I have heard about the Git some time ago.  I have also watched the above mentioned video by Linus Torvalds.  And again, it was a bit not-matured implementation for Windows in the time.  I tried something small, but I did not switch in that time from CVSNT to Git also because I would take some time to adjust the other tools, and I did not learned it enough, and had a lot of other work to do...  I have also thought about switching from CVSNT to SVN -- partly also because there is a transition way from SVN to Git.  However, I decided not to do so because the CVSNT and SVN are not that different in principle, and it would complicate the project.  I am occasionally using SVN passively (getting the snapshot of sources of the Doxygen project), and I did use passively also the Mercurial the similar way (passively, when translating "Dive Into Python 3" by Mark Pilgrim) which can probably be compared with Git concerning the principle of a distributed VCS.

The pragmatic view is: Git has proven its vitality, it is powerfull, and it is not going to die soon.  I am waiting for the following discussion.  Please, mention whether you use the Windows o Unix/Linux.
What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

>>My guess that majority of programmers do not have a formal education in
>>Computer Science (university level).  Because of that they often do not have
>>a big picture of the project infrastructure (the reasons why the things are
>>done this and that way, using the tools,...), and they do not see the
>>alternatives.  They are just happy with what they have.

It gets worse - since I often get in contact with students from that field (Software Engineering, CS - evilrix and Infinity know where I meet them ;o) I felt tempted to ask which RCS they were told to use. Much to my dismay the answers basically boiled down to "Wuz dat?"
>> It gets worse - since I often get in contact with students from that field
>> (Software Engineering, CS - evilrix and Infinity know where I meet them ;o)
>> I felt tempted to ask which RCS they were told to use. Much to my dismay
>> the answers basically boiled down to "Wuz dat?"

I know that situation very well.  I was teaching at CS department for eight years (until 1997).  I could observe the tendency of more and more "dumb" students.  I do not like to say that, but it is true.  There are definitely reasons for the situation.  Briefly, more students are allowed to study, underpayed teachers often go to industry for better salaries, chidren now can have a lot of things and they are not "trained" to cope with difficult situations, to solve problems.  They are not trained to focus on a problem, they easily give up.  They prefer to consume and to play before to create and to look for themselves.  But it is for another thread...

Frankly, I did not learned about VCS's at the school either (graduated in 1988).  It was behind the iron curtain, personal computers were just few there.  Also the style of programming and of organizing the team were different.  Almost no Internet-like things, etc.

I suggest to return to the theme of the favourite Version Control Systems and why... :)
evilrixSenior Software Engineer (Avast)Author Commented:
>> I don't think that git imposes a workflow

That's not actually what I said. If you read my comment again you'll see I was implying that Git is flexible and, thus, allows me to adopt a workflow that suits me; unlike SVN.

Yes, branching in Git is cheap. It creates one 20 byte file; job done. Merging even thousands of lines of code is as cheap as updating that 20 byte file, if you branch has not diverged from its parent (ie, as long as it has a direct root back to the tip of the parent). Even if you branches have diverged it is rare for Git to take longer than a second to perform a full merge.

Git doesn't impose branching any more or any less that SVN but it makes it a damn sight simpler.
Which VCS you use depends largely on the situation, and the way the team/company/project works. So, there's no one perfect VCS out there that suits everyone all the time.

At this time, I'm using SVN for almost everything.

For personal projects, I prefer SVN, simply because it's straightforward, and I really don't need more.

At work, it's used because it makes sense for a few reasons :

* we need a central repository that is the reference (it ensures work isn't lost when people leave, get sick, ...). Everything is pushed to the central repository as soon as it makes sense to do so. Each team member has his own personal way of managing things locally before pushing to the central repository. Some prefer to push regularly, others take a bit more time. Some create branches for bigger projects, others have a local repository they work in, which is eventually merged back into the central repository (emulating a DVCS in a crude way I guess).
* we need a stable, mature, well-supported VCS, for obvious reasons.
* it needs to be cross-platform and free (for practical reasons).

At the time, the VCS that best fit these needs, was SVN, and that choice has not caused us any trouble (apart from certain limitations that I haven't seen addressed in any VCS to date).

If at some point, a new VCS needs to be set up in a team environment, then Mercurial is likely to be at the top of my list though (with SVN as a close second). I've worked with it quite a bit on a previous job, and it feels very natural. It makes having multiple levels of (local) repositories quite convenient eg. But the added advantages do not justify the effort of switching from SVN at this time.

I haven't played around with GIT yet. At least in nature, it appears similar to Mercurial, but none of the arguments Linus makes in that video really convince me that it's worth to make the switch either. A lot of the advantages he mentions just don't apply to me :

* implementing a central repository model like we use it at work eg., would seem to defeat the point somewhat - ie. we wouldn't really take advantage of the distributed aspect.
* a better performance is nice, but shaving off a few seconds every day doesn't strike me as that important.
* fast merges are nice too, but I just don't merge that much. And it tends to be the non-trivial merges that take up most of the time anyway (and those still need to be resolved manually in GIT).
* a content-centric (as opposed to file-centric) VCS sounds useful to someone like Linus, who is juggling with (sub-)projects, rather than with files, like the large majority of developers do.

So, although I do intend to play with GIT, I have seen no evidence so far that it will be the major positive change that it's advertized to be. It's just another VCS, that will be useful for some people/projects, but I don't see it taking the world by storm.
I've used many VCS's, including CVS and SVN.  Mostly use GIT now.

GIT can be confusing and complex.  Possibly this is a documentation issue, although there are a number of tutorials and articles about it.  Some areas, like sub-projects, are less than clear.  
You may want to know that there is a book related to Git.  It is named "Pro Git", by Scott Chacon under Creative Commons License --  I have just started to read it, no opinion yet.
At the moment svn is still my favourite for both big and small projects.  The great thing about it is tagging.  I haven't tried git yet.  Hopefully it is as fast as svn in tagging.  All over VCSs seem to take forever, especially on large projects.

I once worked on a project in PVCS.  That took 2 hours to do the tagging.  When they shifted to MS teamware, it took 10 minutes.  In svn, it is about 2 seconds, regardless of size of project or how many checkins have been done.

The nasty thing about svn is it allows you to unknowingly wipe out   entire project trees.  You then have to go through the trouble of reconstructing the tree from an older version.
I would like to expand this very interestion question in another direction.  Please, have a look at "What is your experience with the transition to the chosen Version Control System?"  http:Q_27327248.html.  It should be namely about expectations before and after, about your experience and abou the experience of your co-workers.
evilrixSenior Software Engineer (Avast)Author Commented:
>> So, although I do intend to play with GIT, I have seen no evidence so far that it will be the major positive change that it's advertized to be

Before I started using Git I felt exactly the same way; then I actually tried using it. Initially I was like, wooah, this is a little complex. Once I got past that stage I realised just how powerful and flexible Git is and how it makes SVN look and feel like a dinosaur. I could never go back to using SVN now. Even if I do have to work with an SVN repo I do so via Git.

The thing is that Git has soooo many powerful features that, until you've actually worked with it for a while and learnt them, you just don't realise what you've got your hands on. It's easy to dismiss Git as just another VCS but it is so much more than that. It really does change your how development workflow -- for the better.

Of course, I know there is no convincing anyone who is a die-hard SVN fan so all I can say is just try Git. There will be a learning curve; it is not as simple as SVN but it is way more powerful.

>> The great thing about it is tagging
SVN's idea of tagging is identical to branching -- it just takes a complete copy (the reason it seems to fast is because it does something similar to copy-on-write, but it is still taking a copy). This means you can do stupid things, like commit code on top of a tag!

>> Hopefully it is as fast as svn in tagging
It's as slow as it takes to write a SHA1 to disk.

>> In svn, it is about 2 seconds
It takes about 2 microseconds in Git, but as Linus alludes in the video I link I posted at the top. Focusing on the time it takes to branch or tag is only half the picture. Ask yourself, when branching how long does it take SVN to merge back a branch? In generally, my experience is it take an awfully long time and often screws up. In git it also takes a few microseconds (as long as it takes to update a SHA1) if you branch has the same parent as the branch you are merging with (99% of the time). For disconnected merges it still generally takes a second or so.

>> The nasty thing about svn is it allows you to unknowingly wipe out   entire project trees
Git also lets to you do that. Conversely, Git also allows to recover them.

git branch -D foo # kill the branch
git reset --hard HEAD${1} # undo you last action

NB. HEAD${N} is like a command stack and you can revert back to any of them, even after a destructive action.

>> I haven't tried git yet
Try it. I can almost guarantee that once you've spent a little time learning it (it is quite different from SVN in a number of areas so there is a little bit of a learning curve) you will wonder who on earth you suffered SVN for so long.

Incidentally, if your company insists on using SVN, that's fine cos Git allows you to treat an SVN repo as just another Git repo. You can clone your SVN repo, work in your own Git clone and then push your changes when you are happy with then. The thing with Git is that it's so flexibly it can accommodate nearly all workflows, even those that use other repos.

>> What is your experience with the transition to the chosen Version Control System?

Great idea, I'll contribute a little later (really gotta go do some work now!).
evilrixSenior Software Engineer (Avast)Author Commented:
Thanks everyone for your thoughts.

Points were awarded to the first comment to everyone who shared their VCS usage experience.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now