SVN AND MERGING

An instructional document on
how to code on with a team
Our Goal
To answer the basic questions that ring up
regarding team development systems.
 Why are there problems?
 SVN / CVS
 What can I do to help avoid these problems?
 Folders
 Team Merging (Nominees)

 Project Management

 What can I use to help avoid these problems?

 WinMerge http://winmerge.sourceforge.net/
 Tortoise SVN http://tortoisesvn.tigris.org/
 Tortoise CVS http://www.tortoisecvs.org/
Defining the problem…
First things first, Lets look at a
very simple example.

A single user is able to very

simply edit information in a given
folder with no problems. If they
are trying to modify a file they Bob
open it and they edit the file,
saving when finished.

A very straight forward method of

editing information in directories.
You may have already
experienced in this because of File Modified
your usage of computers up to
this point. You have edited your
own files many times. Lets start
looking into how things change
with another person added to the
system…
Bob Wins!
Defining the problem…
So things have
changed. Bob is now
working with a
number of people, and Bob Pat Mike
he has a few things to
worry about, such as
the obvious problem…

Who gets to touch the

files?

Directory Structure
Defining the problem…
If any two people open up a file at the same
time, they may run the chance of over writing the
changes that the other person may be making.

Pat

Bob
File Modified Bob FTW

Mike
Why is this a problem…
 Because Everyone needs to have the ability to
code, or they are wasting their abilities.
 Productivity & Time are lost if there is no system
used to monitor and oversee this process

Possible Solutions
 Communication
 Merge Nomination
 Management
 Locking or Read Only
 SVN / CVS Systems
Communication
Lets go back to our previous system and set up a system of
communication in which the users are using AIM or MSN to
communicate their current steps, for instance…

Bob would tell Pat that he is editing somefile.cpp,

and that Pat shouldn’t touch it.
The problem is still here. Pat is morally
bound to listen to what Bob says, Which
works very well for Bob, but if Pat forgets
that Bob is editing the file than Bob’s
changes are lost to cyberspace.

This shouldn’t come down to moral or

decisions. It should be simple and easy to Pat
follow.

This system is limited, in that you should

have the entire team notified, and when
you have a large team you may end up
with a large email listing of people who
File Modified Bob FTW
may not check their emails as often as they Bob
should.
Merge Nomination
One system that I have run into a number of times, and
works on the broad scale, is to nominate a person to have
the ability to merge their code and only allow that person
to merge their code, while the rest of the team does not
have the ability to update the files.
This system is legitimate, in that it allows
modification of files as the users see fit. The only
problem is that there is a very big problem with
speed and efficiency. In order to pull this system off
there is a cycle that has to be kept running in order
to assure that the process does not lose time.
The problem is that the conch does not get passed
as often or quickly as it should be, and the coders all
Pat Pat FTW
have to have an understanding of what the other
users are doing and they have to have the ability to
jump into the code that you have been given and be
able to pick and choose what you need to ask. This is
easiest using applications that monitor merging. Files Modified
This system is not limited by the number of users, Bob Bob FTW
but it becomes very slow and tedious when the
groups get larger than 10 people.
Management
Both of these options require the users to be overseen for best results.
This instills some very inappropriate things in the users. No one likes
being watched every step of the way. Programmers are a notorious bunch
of people who rebel against oversight. Many people have written about
how terrible management can be, and although you may not have
read them, you shouldn’t have to think so
hard in order to come up with a few
complaints of your own.
Locking or Read Only
Both of these options are equivalent to the
communication option, in that a single user has the
ability to edit a file. The only change is that instead of
telling Pat I don’t want him to touch a certain file, I lock
or make it read only. This way pat at least has the ability
to read the file.

The same problems persist. Pat is still

very dependant upon my progress and
likewise so am I on his.
Pat
This impedes my progress while he is
working, and shows us that we are
wasting time in this method of
versioning our code.
File Modified Bob FTW
Bob
What are some other
options?
 Having multiple folders?
 Working on a default code base, keeping
track of all of our changes (differentiating)
 Subversion
 Concurrent Version System

 Give up, get drunk, die?

SVN v. CVS
A debate could go on for hours comparing these two items, they
are equal and both capable of becoming useful under similar
situations. I would recommend SVN because I have found that
people have an easier time learning it. One thing to keep in mind is
that these methods do not take any of the management process
out of your hands, they just keep track of files…

Here are their respective sites

http://ximbiot.com/cvs/

http://subversion.tigris.org/

The only problem is that you have very little ability to modify or
update the versioning system without a tool…

Enter tortoise.
Our Method of Management
Over the last few years I have been learning more and more about taking
care of code in a team environment. I have come to a conclusion that
merges much of the ideas that we have already pointed out.

Our method is simple, but comes with a check list.

Our Method Of Management
Since we are already using SVN, I will focus on this method of
system management, along with the idea of using multiple
folders, and merging.

Lets look at the example in which three people are working on

the same code base. The problem was that we would be
overwriting or blocking the process of change on another
persons part.

Lets answer the problem step by step. Bob Pat Mike

Blocking – This taken care of by the entrance of multiple

folders. The process is very straight forward; you never lock,
set read only, or have to worry that anyone is working on a file
because you only have your own code.

Overwriting – This is controlled by the process known as

merging. I recommend that you use an application, such as
winmerge, in order to run a differential on the files that you
have been modified against the files that you have in the
second directory. This is also dependant upon the multiple
folder system that we highlighted earlier.

Directory Structure
Our Method Of Management
This system that we are using requires a bit of disc space and doesn’t take
too kindly to anyone who cant tell the difference between debug and beta
builds, but in the end it causes little or no frustration.

The requirements of this system to stay simple and sane are as follows:

• Do not upload anything to the SVN without confirming

it works with the current code that is on the SVN.
• This is done by downloading the current version and merging your
code into it.
• “works” means that you have merged, and confirmed that your
code functions properly, allowing no unforeseen issues (A/B Bugs)
• Make sure you download the latest version of the code off of the SVN.
• Make sure your code works as you planned it to work.
• Do not overwrite, delete, or in any other way modify another persons
code for any reason without notification to that person, and properly to
the team.
• Always fill out the log in the SVN updating utility, listing what your code
does and what it affords the application (in other words, explain the
purpose of your update).