Improve company productivity with a Business Account.Sign Up

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

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

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,
  • 4
  • 3
2 Solutions
evilrixSenior Software Engineer (Avast)Commented:
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 :)
peprAuthor Commented:
@evilrix: Do you use Linux or Windows?
evilrixSenior Software Engineer (Avast)Commented:
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

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

peprAuthor Commented:
Can you compare using Git on Windows and on Linux?  

What kind of Git for Windows do you use -- cygwin or msysGit?
evilrixSenior Software Engineer (Avast)Commented:
>> Can you compare using Git on Windows and on Linux?

>> What kind of Git for Windows do you use
The official Windows client -
peprAuthor Commented:
Thanks, evilrix, for sharing the information.
evilrixSenior Software Engineer (Avast)Commented:
You're welcome.
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

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

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