Svn And Merging

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  Tortoise SVN  Tortoise CVS 

http://winmerge.sourceforge.net/ http://tortoisesvn.tigris.org/ 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 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 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

File Modified

Bob Wins!

Defining the problem… So things have changed. Bob is now working with a number of people, and he has a few things to worry about, such as the obvious problem…

Bob

Pat

Mike

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 Mike

Bob FTW

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 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 may not check their emails as often as they should.

Pat

Bob

File Modified

Bob FTW

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 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. This system is not limited by the number of users, but it becomes very slow and tedious when the groups get larger than 10 people.

Pat

Bob

Pat FTW

Files Modified

Bob FTW

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.

Bob

File Modified

Bob FTW

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).