Improper Use of Version Control

Question

I have started working recently in driver verification for a hardware company. The work is writing short software tests that verify known issues, bugs and possible faults anyone can think of.

Now, in the course of my basic training for the role here I have come across an ugly practice of version control usage. The company uses SVN for holding versioned code repositories. But it is done in the most abusive fashion I have ever seen.

The repository is treated as a versioned drive, so to speak. The trunk, tags and branches are totally ignored and neglected, and the work is done only in arbitrary directories located at the repository root (beside the trunk). Furthermore, the repository stores a vast amount of projects, that should be divided into smaller project repositories.

In addition to that, the entire daily work practices with the version control are abusive. The commits are treated as carved in stone, kind of like tags. Each commit triggers a mail to be sent to 10 different people - including 2 levels of managers. My manager even told me to commit more sparsely - once a day or two - because he receives too many commit mails. Mike Mason would have gone berserk.

I have read books from the pragmatic bookshelf, including Pragmatic Version Control using SVN, and there seems no knowledge of this around here. I really believe, from my own experience, that the practices discussed in these books help people work better, and better accomplish day-to-day goals. I would have liked to see a bit of these practices propagate in the workplace.

I was suggested a few ideas so far as to how to approach this. But I would like not to specify them here, so as not to dictate the sort of answers I am looking for, but have an open stage to suggestions of all sorts.

How would you approach such a case?

Answer 1

Personally, I'd suggest the resign approach. You're not only fighting the status quo but also your manager.

Failing that, gather your evidence and approach the next manager up with a proposal for a better way of doing things. Focus on the positives of what you want to do, not the negatives of what they are currently doing. Show them what they gain from the new approach, not the pitfalls of the old.

Answer 2

This is much more a human/business/political issue than it is a technical one. You will have to sell to management the benefits of changing the approach.

What will be the ROI for implementing a different scheme?
Can you point to specific examples which cost the company something (time, defects, rework cost) that would be demonstrably reduced by implementing another scheme.

The fact that it's abusive/ugly/offends people's sensibilities is not enough. Remember, there will be retraining costs involved if you change the scheme.

If your concern (which I find totally valid) is that you are asked to limit your checkins, you could always setup a local repository for your "work-in-progress" and once you are happy, copy the files to the "official tree directory" and check that in.

Ugly, a burden, and no fun. But you would have a more granular history (of your mods)...

Answer 3

Perhaps try to set up another repository which you and the other sane developers can commit to more often? May not be feasible, but worth a try.

Also may want to mention that the repository is effectively also a backup system?

Answer 4

The first thing I would do is to map all of the existing branches on paper. Who is using them? What is their purpose?

The second thing, is to decide exactly what the branching strategy should be. In our case, we branch only under two circumstances: 1. Released code (for easy hotfixes); and 2. Feature branching when we have two versions that are very different with short release timeframes.

In the case of the second option, someone is responsible for merging them back together as soon as feasible.

Next, I would look towards setting up a new repository, and migrating everything into it in the right places. Do this one project at a time until you can retire the old nightmare.

In the process, I would look at all branches of the existing project and merge those as necessary. As you merge them together, close and use security to lock down the dead ones.

At the end of the day, you'll need manager support and buy in. That's in case the rest of the team starts fighting you.

Answer 5

I think that your question is more about changing the way your company is working rather than a about version control. It is sometimes difficult for a new employee to change the habits of a company and you might be rejected by some of your news colleagues if you try to change everything. However, it seems obvious that you have to :-)

My approach would be to start speaking with people and try to understand why they are working that way. Maybe you are going to discover some acceptable reasons. But, I am sure that you are going to help people discover that this is wrong and that your approach of a version control system has a lot of benefits for your company.

I hope this helps

Answer 6

I would suggest to start small. If you are working a certain project try to get a clean and "right" used repository or part in the repository for your project. Do not try to start a big fight. Wait for a good moment eg. the start of a new project and then try to start small. And have all the literature at hand to back up your bidding for this small first step.

Then try to show at this small project why your approach is superior to the overall approach and get the developers on the project with you and hopefully some of the managers on your side. If they are certain that your way is a good way. Maybe the next time a project is started the try it in a cleaner way too.

There is no way overcoming corporate practice in a fast way. The people working there are used to their versioning system for a very long time.

Answer 7

"This is much more a human/business/political issue than it is a technical one."

I agree with that comment. This repository is being treated as a "release" branch. Don't challenge people's preconceptions head-on by suggesting any change in how the "master" repository works, but lobby for adding what you need: a section of the repository for "works in progress" or development which doesn't have the same emergency email alerts and is organised a more normal way, or a separate repository (either centrally or only on your computer) which you can merge "finished" versions into the "master" repository from.

Answer 8

Somebody, somewhere in the company probably thinks the current VCS organization and workflow is valuable.

They're probably wrong. :)

But if your proposed change would eliminate that perceived value, it's unlikely to get very far.

On the other hand, from previous experience and Pragmatic Programmers, you know there are other ways VCS can be valuable.

My suggestion would be not to try to change the current workflow -- at least right away. Instead, pitch your proposal as a way to get more value out of the system you already have: "As long as we've already got the overhead of maintaining a Subversion server..."

Maybe this means creating additional repositories, a new, more traditional parallel workflow -- pitch it as "scratch" or "sandbox" or something like that, something non-threatening -- setting up svnmerge to manage/control merging from the new workflow into the old one, whatever.

But concentrate on the positive benefits, cost/effort savings, etc. of your new system, rather than on the freakishness of the old one.

Once that's in place, and people are used to it, you can start asking questions like:

• "Do all ten of you really find it helpful when you get a commit message?"
• "What happens when you get one for a commit you don't like -- do we have a workflow for that?"
• "Would we be better off with continuous integration instead?"

By then, you'll have a rep as somebody worth listening to. And people will be more likely to listen to you when you call for slashing and burning. :)