According to the slide, the flow is as follows:
1. Create a branch from trunk and commit.
$ svn cp ^/trunk ^/branches/mybranch $ svn co ^/branches/mybranch
2. Inside your own branch, mybranch in this case, you need to keep in sync with the trunk.
$ svn merge ^/trunk $ svn co
3. Later, once the features in mybranch is completed, you will need to reintegrate to the trunk. Inside a clean copy of trunk, run these commands.
$ svn merge --reintegrate ^/branch/mybranch $ svn co
Once integrated, the branch is basically end-of-life. No more modification to it. This is one step which I did differently, basically we have a stable branch which actually act like trunk. Why ? I spend most of my time in stable branch and hardly touch trunk. That why.
However, the --reintegrate option has deprecated in version 1.8. Subversion will automatically decide a reintegration merge or not.
4. One integration is done you'll need to tag it.
$ svn cp ^/trunk@12345^/tags/mytag $ svn co
5. Rinse and repeat.
There is still one question lingering in my head right now. How do I prevent certain files from being modified during merging ? More on this in next post perhaps.
Back to the slides. One particular slide echo my sentiment about the practice of using Subversion or any version control. You need to commit small, commit early, and commit often for each small task. It keeps the momentum going and motivate the team to move forward. This was further enhanced by our practice of Kanban scheduling methodology and Podomoro time management technique. Our development process is getting better but there still room for improvement.
One thing for sure, I need to move the Subversion to a new server. The installation (by yours truly) is seriously way effed up. Should I just migrate to Mercurial or Git? Or maybe I should just use hgsvn or git-svn instead?