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

Posted on 2011-09-26
Last Modified: 2012-05-12
This question is related to evilrix'es "What's your favorite Version Control System (VCS), and why?"  http:Q_27321575.html

Assuming you have chosen the CVS, CVSNT, SVN, VSS, Mercurial, Git or whatever, you probably had or none or a different VCS before.  And you probably have colleagues who want or are forced to use the version control system.  Can you summarize your experience with the transition?

I am going to summarize my own experience.  I lead one of the software project in our company.

Once upon a time, I have started to use the VCS (namely CVSNT) and it solved my pain in the time.  Being grown on punched cards and later on command line, I have always prefered to know what I am doing -- I am using the command line plus some trivial batch files (the most repeated cvs commands), plus some Python script later (to zip differences from some tag...).

It happened that colleague of mine complained about having problems with maintaining all the sources updated by more people.  I had suggested to use the CVSNT, and he agreed.  However, he and his co-workers were not grown on a command line and they decided to use the Tortoise client tool (  Then, it was a bit difficult for me to explain what should be done in some situations.  The problem is that some users do not understand what is behind the system.  They tend to think in terms "some magick thing is done", and they complain if the magick is not the one they expect.

Can you summarize what you see as a problem with your first or another version control system from that point of view?  What was your expectation, what was the reality, how did you cope with that?  How to introduce the vcs to the others?  How to convince them, and/or how to force them to us it?

Thanks for your time and experience,
Question by:pepr
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
LVL 40

Accepted Solution

evilrix earned 500 total points
ID: 36719942
We recently started a migration from SVN to using Git. The actual technicalities of migrating from SVN to Git is pretty trivial since Git offers the git svn command that can be used to clone a repository. Unfortunately, from a logistical sense it's not as simple as that.

Like most, our SVN repo was one big monolithic blob that contained many related and unrelated projects. Also, because there is a known structure to the repo we have a lot of projects referring to others directly. This is never a good design but it's one of the things that happens when you have a collection of projects in one repo.

As part of our migration plan to Git we decided to split the monolithic repo into lots of smaller ones; each would represent one library, application or project. The other decision we took was that no one repo would have any direct dependency on another. The idea is that where the repos live should have no baring on how they reference each other. To facilitate this, the final decision we made was to implement a structured build framework that would be able to build and package our projects.

When developing our build framework can be configured (it auto-configures itself) to find any dependencies for a build and include them. One a production machine our packages will install dependencies (such as libraries) into standard installation paths (eg. on Linux it'd be /usr/local/lib).

The next step was to migrate the repos (the easy part) We've only migrated trunk since we've still got the rest of the history in SVN and it's unlikely we'll every need to work in any of the branches. We then rework all the build code (we use CMake but each project has its own build file -- now the build files are automatically generated using our build framework) in that project. This is actually quite trivial because for the most part it's actually just removing junk that is now auto-generated.

We haven't migrated everything yet, but we have migrated all our core libraries and services. Other stuff will get migrated peacemill -- the next time a bit of code is touched the first thing we do is migrate it. The SVN repo has been set to read-only to ensure this must happen.

All in all it's taken us about 2 months of planning, migrating and reworking code to get to the point where about 50% of our repo is now migrated but because we've now done all the grunt work and planning migration of everything else will be (nearly) trivial.

Was it worth it? Hell yeah! Git has soooo much more going for it that SVN. It's more flexible, it's way faster, it's trivial to branch and merge (SVN merge == SVN hell!) and because I work from home a lot the fact I can work in my own local repo and only need to push once I am happy makes life easy.

We also implemented a more formalised code review process. All code is pushed to our master repo service via the Gerrit code review system. Anything pushed to master (Git's version of trunk) generates a code review and blocks merging into the definitive repo until it's been reviewed and approved by at least 2 other developers. All other branches are open since we all work in our own experimental branches and only merge back to master when we are happy with what we have -- and Git makes that an almost trivial workflow.

I can't rate Git high enough. Lots of existing SVN users will poo poo it because they don't see the point. It actually makes me laugh when they do. Until you've used Git and experienced the freedom it gives you over SVN you really have no idea. It's like saying you don't like a certain food without even trying it! Also, the other argument is often - "but I work for a corporation and they insist we use SVN" or "SVN is structured just like our team". Guess what, that's fine. Git is so flexible it will let you work that way.

You can use git svn to close a SVN repo. Work in that repo just like it was a Git repo and then (and one when) you are happy with all you changes you can push them back to the SVN repo. Meanwhile, you have all the benefit of Git -- local commits, the ability to rebase your commits, the ability to branch and merge at will (99% of the time branching and merging is as expensive as it is to write a SHA1 to disk -- that's how cheap branching and merging are).

Well, that's about it. I could probably go into more detail about what we did and how much I love Git but I'd probably be in breech of some confidentiality agreement if I did and I'm sure anyone who really wants to know how wonderful Git is will check it out and those who can't see the point won't bother -- which is just fine by me :)
LVL 29

Author Comment

ID: 36813035
@evilrix: Do you use Linux or Windows?
LVL 40

Expert Comment

ID: 36814231
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 29

Author Comment

ID: 36814436
Can you compare using Git on Windows and on Linux?  

What kind of Git for Windows do you use -- cygwin or msysGit?
LVL 40

Assisted Solution

evilrix earned 500 total points
ID: 36814963
>> Can you compare using Git on Windows and on Linux?

>> What kind of Git for Windows do you use
The official Windows client -
LVL 29

Author Closing Comment

ID: 36899076
Thanks, evilrix, for sharing the information.
LVL 40

Expert Comment

ID: 36900315
You're welcome.

Featured Post

Online Training Solution

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I worked at a US software company that used offshore contractors for ten years and offshore employees for three years. We had a positive experience and you can too.   When I interviewed people for positions in the US, I would tell them that we wor…
A simple overview of the possibilities of using technology for project management.
The viewer will learn how to user default arguments when defining functions. This method of defining functions will be contrasted with the non-default-argument of defining functions.

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question