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

Try this. I found it on an 'SVN for dummies' search and it was described as a 'SVN for Dummies, a guide your grandma can understand' :D

Answer 2

Give them a brief talk on svn. tell them what the benifits are and how to use it.

I managed to pick up SVN in my first job out of University with not trouble what so ever, though I was using it at a file system level using tortoise SVN. I'm not that smart so if I can pick it up anyone can.

Answer 3

A simple "cheatsheet" on the needed procedures, given step-by-step, is the best way. SVN does have some pitfalls that aren't obvious. I've been involved with new people using it, and on occasions they do blow away whole chunks of code from the current revision, etc. Of course, you can always go back and get from previous versions, but SVN is scary and hazardous to new people. Keep that in mind and write very simple but explicit instructions for the needed operations!

Answer 4

<sarcasm on>
Let them try SourceSafe for two weeks
<sarcasm off>

Answer 5

If they are mostly students, one selling point is that out here in the "real world" many people take versioning very seriously.

If they are afraid of deleting something, demonstrate deleting some crucial file and demonstrate the ability to restore deleted files.

Or they might like a different kind of version control all-together suchas git or mercurial.

Answer 6

Here is a decent SVN "cheatsheet" that describes basic usage: http://abbeyworkshop.com/howto/misc/svn01/

Answer 7

Run through some scenarios with them on why version control is good. Even better, put them through some toy projects where time pressure makes them commit frequently. In some allow them only to share code through svn, and in others to share it only through shared directories.

After that they'll know what it's about.

Answer 8

K make your friends read this. Next learning the cli first on a few pet projects clarifies this greatly. My first go at subclipse about made me hate eclipse. Partially because I had never used subversion before.

• checking out = get a local copy of the code that is in the repository.
• Update = makes sure your local copy is up to date with the master copy. aka the server.
• commit = add your changes to the master copy
• merge = you plus someone else has committed since you checked out. merging allows for you to keep BOTH sets of changes via a little supervised editing.

Merging is a neat feature but a bit complex at first go.

Answer 9

I would suggest them reading at least the basic parts of http://svnbook.red-bean.com/en/1.5/index.html, it is well written with some humor thrown in. It covers using the command line tools, but the concepts are the same no matter what interface you are using (i.e. TortoiseSVN or Subclipse)

Answer 10

SVN keeps track of all changes since the project start, so there's practically no way to throw away your work just by hitting the "wrong" button. I really think that all significant work should be under version control, even if there's no team (I code alone and I use it).

I never really saw the point until I read this little book, try to make them read at least the first 20 pages. There's a good analogy there between subversion and the "undo" button of any editor, that may convince them of using it (it worked with me :) )

Answer 11

"How can I make them like version control?"

Delete their working copies and they'll quickly grasp how useful version control software can be!

Seriously, using VCS is something that goes hand-in-hand with being a mature developer. If you don't know why you'd want Subversion, I wouldn't trust them as developers. They may have skill programming, but programming is only a part of the job of being a developer.

I do believe that until you've lost code, you'll truly never appreciate VCS.

Answer 12

• unlimited undo - no need to worry about lost changes
• backup, not your responsibility any more
• 'time machine' functionality - what did the code look like on last Friday evening?
• collaboration
• central, "official" version of the source code makes easy to build releases
• comparison: someone dared to touch your code, what did he change exactly?
• tagging: tag stable versions which are ready for demonstrations, you can keep developing in the code base after

The 'merging' only needed when two developers modify the same line in the same source files. It doesn't occur very often in small teams and it takes a couple of minutes to fix. All other changes merged automatically by the version control system.

Answer 13

Send them to:

• http://svnbook.red-bean.com/
• http://www.ericsink.com/scm/source_control.html

Impress upon them that they will be denigrated as complete and utter fools by anyone who uses a half decent source control system (i.e. not VSS).

Answer 14

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.

Answer 15

You need to really sell them on the concepts of version control first so that they understand how svn works.

A few things to try are

• Create a sandbox repository for training and experimentation
• Try to organise some training sessions/ workshops. If you're not confident in running that your self, try chatting to your local Linux User Group to see if they know someone who can help.
• Document your development process including the common subversion usage scenarios.

Its also worth pointing out to the students that experience with source control will be a plus for their CVs.

On your specific issue of committing .project files you can either set the svn:ignore property on a property or you can set the global-ignores value in each users subversion config file.

Answer 16

You can't really make anyone like it. But if you just start using it yourself and set a good example, the benefits will become apparent. You need to update the server constantly and make sure the server is backed up. That way when there is a crazy bug in the system you will have the logs to show the change that caused the bug. You know what you need to do. Don't let the ignorance of others stop you.

Answer 17

You might want to create aliases for the most dangerous commands (I'm thinking mostly of revert) that would require explicit confirmation before calling the svn command.

Also, if they're using Eclipse, they can set up their editor so that it will keep N work copies of the current code. I've saved myself from a couple of stupid version control mistakes with that feature.

Answer 18

They can always try "the poor man's CVS": have them do a ZIP of their code a moment before they check in/out anything, and store them numbered somewhere in their hard drives.

In the end, they'll have a bunch of files like:

• MyProject01.zip
• MyProject02.zip
• (etc)

This shall give them the piece of mind that their "work" will not get "destroyed" in case they do something stupid, and will be cumbersome enough to force them to learn how to use SVN properly (come on, it's not that difficult!).

I've personally found this poor man's approach to be far superior to Visual SourceSafe: at a former employer's I was forced to use that monstrosity... after the second time the repository completely broke down, they thanked me for this :D

Answer 19

If you are developing in windows machines, try to use TortoiseSVN as your subversion client. The interface is really great. I will help them to loose the version control fear.

Answer 20

Version control greatest problem is the conflict resolution. If you really want to play safe, try this workflow:

1. Every developer create a branch from the main trunk before starting to code;
2. A developer implements a feature in his own branch and commit (no need to update, since he is the sole developer in his branch);
3. A couple of more experienced developers review the code, test and merge the branch revisions to the main trunk;
4. rinse and repeat

Subversion 1.5 new features are really great for this kind of workflow.

Answer 21

Its all about confidence in using something new, and understanding what it is that they're using. Once you've used it, are happy it works, the 'disagreement' disappears.

Try a training overview first - here's a project that provides some powerpoint slides to help.

Give them the svn book and links to TortoiseSVN to read up on it once they have the overview.

Then try a hand-on workshop with a sandbox repo.

Then be available to assist for a week or so while they use it for real.

this approach works for everything, not just SVN.