On Trunk we will commit the latest version of the code
On Tags, certain versions of the code will be kept (for history / not for active development)
e.g. ver1.0 (autonomously around the building)
e.g. ver3.0 (ACE scenario)
On Branches, different paths of development (experimental or for bug fixing)
e.g. Experiment with next ROS version
-> Create new branch (copy from trunk)
-> Update all algorithms, interfaces
-> Make it stable
-> If ok, move it to trunk
e.g. Fix a serious bug
-> Create new branch (copy from trunk)
-> Fix the bug slowly
-> If ok, move it to trunk
So, I am changing the svn structure like this:
- Trunk
- ACE
- Driver
- Configuration
- Docs
- Branches
- Tags
On Trunk we will commit the latest version of the code
On Tags, certain versions of the code will be kept (for history / not for active development)
e.g. ver1.0 (autonomously around the building)
e.g. ver3.0 (ACE scenario)
On Branches, different paths of development (experimental or for bug fixing)
e.g. Experiment with next ROS version
-> Create new branch (copy from trunk)
-> Update all algorithms, interfaces
-> Make it stable
-> If ok, move it to trunk
e.g. Fix a serious bug
-> Create new branch (copy from trunk)
-> Fix the bug slowly
-> If ok, move it to trunk
More here: http:// ariejan. net/2006/ 11/24/svn- how-to- structure- your-repository /
Any comments?