How do I make my colleagues not despise SVN?

Question

Many of my colleagues use SVN in groups of 1-5 people partly working on the specific project. Half of them are inexperienced students. In fact non of us are real software developers with year-long experience. Most of them use Eclipse and subclipse to read and write their contributions to the SVN repositories.

Some of them have problems with the difference of:

• checking out (confused with update and merge)
• commiting (confused with update)
• updating (confused with commit and check out)
• merging (is the hardest. Whats a merge? Do i have to merge my code "into the SVN"?)

They fear that the SVN might kill their work (they don't call it working branch) if they press the wrong button.

They are committing their eclipse .project files to the repository, after adding some arbitrary library dependencies to their java projects. The other colleagues get compilation errors from these comitts and find it hard to resolve these.

In general they say: I'd like to work without SVN, I don't like it. It's too complex.

Is there a e-learning project like "SVN for kids"? How can I make them like version control?

Answer 1

In my experience, one of the main reasons why so many people are "afraid" of, or don't like, version control is because they don't understand the underlying concepts and how the system works. This is, unfortunately, also true for many experienced developers. I know people who have used CVS and Subversion for years, but they never create branches or tags, because they don't understand how they work, and therefore see them as "complicated" or "unnecessary".

I think it's essential that your co-workers gain a basic understanding of the purpose of version control, the reasons for using it, and the workflow involved in doing so. Personally, I think the first two chapters of the Subversion book provide the best explanation of the involved concepts and the theory behind version control systems in general, so I recommend your co-workers to read those.

I do not recommend using an IDE integration to learn using version control. Integrations and plug-ins often hide the "details" of the system from the user, which can be very confusing, especially if you don't know what things looke like "under the hood".

I prefer tools like TortoiseSVN, where you perform most operations directly, and manually, without any "magic" behind the scenes. For example, a very common misconception is not understanding the difference between your working copy and the repository on the server. I have often seen that switching to a tool where you operate directly on the file system will help with this situation, because the user is forced to activeley think about what he is doing, and why.

As with pretty much everything else in life, using version control is also done best by personal experience—trying and failing, and trying again. This is why I recommend creating sandbox home folders for everyone. Allow them to experiment with the various functions in the system without the fear of destroying anything in the project or losing data.

Answer 2

First, you need to take a "software-independent" approach at looking at this problem. Don't force them to read the Red Bean book, or try telling them about all the nifty SVN commands. Instead, you should start by trying to teach the proper workflow with version control. In a nutshell, that means:

1. Update your view
2. Make some changes
3. Test your code
4. Update again
5. Solve merge conflicts, if necessary
6. Commit

Note here that I'm excluding the initial check-out process, as you should be there to help them check out their initial view. The above steps is only what SCM-enabled developers should do every day (btw, you should also really emphasize that, or else people that have a fear of merge conflicts will only get worse over time).

The key to successful SCM adoption is twofold; first you need to get people used to working with the software doing normal, non-painful things (ie, update/commit). If you don't do this, then the developers will tend to avoid using SCM until you bother them about it and ask why they haven't committed any code in two weeks. Second, you need to teach people how to overcome the common painful scenarios which might cause them to loose their work.

It is indeed possible for an SCM system to destroy work, and it usually happens before anything gets committed to the repository with merge conflicts. You should simulate merge conflicts, walk them through resolving them, and then have them do the same on their own. You should explain:

• What the meaning of the .r1, .r2, .mine, and the original file will contain after a conflict
• Show how to graphically resolve the conflicts
• Now re-compile and test the software again just to make sure
• Make a backup of the .mine file, again, just to make sure
• Then commit

There are many more complex things within SCM, and this should only be explained much later after the basics are well understood. Don't even bother mentioning merging or tagging or anything like that until they have a few weeks of everyday experience under their belts. Otherwise, the complexity and additional risk will make this new tool seem even more "useless" to them.

Again, the key here is to emphasize the daily SCM workflow, in a software-neutral manner, and slowly explain the quirks of the particular SCM system as they come up. Merging is the only complicated thing that needs to be explained at first, as it is likely the only painful thing encountered on a daily basis. Everything else should be explained as it comes up.