== Working with svn branches

It is highly advised to read the following two sections on the branch merge chapter of subversion:

Branching and merging chapter:
   http://svnbook.red-bean.com/en/1.6/svn.branchmerge.html

Creating branches:
   http://svnbook.red-bean.com/en/1.6/svn.branchmerge.using.html

Merging a branch:
   http://svnbook.red-bean.com/en/1.6/svn.branchmerge.basicmerging.html


In practice with your AIP account, to create a branch:

> svn copy https://svn-und.ida.liu.se/courses/TDDD10/2011-ht1/aipXX/team/trunk
           https://svn-und.ida.liu.se/courses/TDDD10/2011-ht1/aipXX/team/branches/THENAMEOFTHEBRANCH

Where you replace XX with your group number and THENAMEOFTHEBRANCH with a better name (for instance, your own name).

If svn complains that the directory team/branches is missing, you need to 
create it:

> svn mkdir https://svn-und.ida.liu.se/courses/TDDD10/2011-ht1/aipXX/team/branches/

Then, when you want to work on your branch, instead of checking out "trunk", you will checkout "branches/THENAMEOFTHEBRANCH":

> svn co 
https://svn-und.ida.liu.se/courses/TDDD10/2011-ht1/aipXX/team/branches/THENAMEOFTHEBRANCH 
team

You need to bootstrap, configure and make as usual. Then you can keep commiting in that branch.

Now if you want to merge your branch back into trunk, so that is available for the final tournament:

> svn merge ^/trunk

Fix any conflicts that might occurs and then:

> svn commit

And in a working directory with *trunk* checked out:

> svn merge --reintegrate ^/branches/THENAMEOFTHEBRANCH
> svn commit


== Collaborate on the same code with your fellow students

Even if you decide to use branches, you will need to make sure that your code does not conflict with other members of your team otherwise you will have trouble to merge back your changes before the final tournament.

When collaborating on the same code base, the main question is which part of the project is common to each members of the team. Meaning, which files are likely to be changed by each members, and which files are unique to your work?

For instance, for a RoboSoc team, the TeamDecision.cc file is common to everybody, changes in that file are likely to affect everybody. But maybe, in that file, each member will only need to edit one specific function, for instance, if someone is working on improving the defenders and someone else the attackers, then they will edit different functions in the file.


The main advice we can give to you is:
  --- sit down with your teammates and each of you tell which part of the code you will need to modify

And then you can see where you have a possible conflict. But most often, they should be easy to solve. For instance, if two (or three) of you want to use the "coach", then you will get a conflict in the "decide()" function. This can easilly be solved by creating a seperate decideNameX function for each of you, and have decide call each of them. This idea of breaking a function into several functions applies to many other situation as well.

Some conflicts are not really solvable, for instance, if two of you are working on improving the same part of the team using different AI techniques. Then it will not be possible to use both techniques in the resulting team for the final tournament. It is still desirable to be able to merge them together in a single executable, and then to have a run time switch. This will make it possible for you to easily compare which technique gives the best results, and select it for the final tournament. There the best idea is to use two different classes/functions (for instance ScoreSkillNeuralNetwork.cc/h and ScoreSkillGeneticAlgorithm.cc/h).

This is only some idea and basic guidelines, if you are unsure about the best way to avoid potential code conflicts, you are very welcome to ask Fredrik or Cyrille about advices on the subject.