Reputation: 2011
Thanks to some previous help on here with SVN I have started to make some headway with implementing SVN into our company. I am using Tortoise SVN and am just a little unsure about the correct working procedures for creating updates. This is the procedure Im currently following, but have 3 questions (shown in bold).
Based on Akton's very good feedback, I am just updating the question to clarify one final point:
1) On 1st January I create a branch called "implementation of new uploader". I check out the code to my working copy and make changes up until the 20th Jan (checking-in to the branch as I go).
2) During this time two team members have created their own branches, released the changes and merged back into the trunk.
3) On 1st Feb I am ready to release. On Akton's feedback, I merge the current trunk into my working copy (which is my branch). I resolve any issues and then do I commit everything back into my branch? This will now contain the two code updates that my two colleagues also merged into the branch. I wasn't sure whether my branch should now also contain other updates from other team members?
4) Finally I merge my branch back into the trunk - but surely this should be extremely simple because my branch is now almost a mirror image of the trunk but also now contains just my updates?
If my understand listed above is correct, I think I have it!
Thanks for all your help.
Regards, Al
Upvotes: 0
Views: 132
Reputation: 14386
Question - whenever I want to create a branch do I have to checkout the trunk to a local working directory and then use the brancg/tag option in Tortoise? There doesnt seem to be a way of doing this with tortoise without having a local working copy.
No, you do not need a local copy to create a branch. You can do it in the Tortoise SVN "repo browser" from the right click menu. See http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-repobrowser.html for more information.
Question - I'm unsure what I should be doing here - am I merging trunk into my working copy (which is now a specific branch) or am I merging my branch back into the trunk?
You would merge any remaining changes in your working copy back into the branch then merge the branch into the trunk. The goal is to get the changes in the branch back into the trunk.
[Edit: Changed the following paragraph] However, in practise, after working copy is committed to the branch, it is better to merge the trunk -> working copy first and resolve any conflicts, particularly if many changes have been made to the trunk since the branch was made. Once that is done, the working copy -> branch -> trunk merge should be simple and cause the least disruption to others.
Question - once I have released the changes should I be creating another tag Version 1.1/2.0 etc?
The depends on your tagging strategy. Remember each commit has a unique revision number that you can always reference. Tags allow you to find or reference revisions quickly using a more human understandable name. See also Best practice for SVN tags?.
[Edit: Added]
3) On 1st Feb I am ready to release. On Akton's feedback, I merge the current trunk into my working copy (which is my branch). I resolve any issues and then do I commit everything back into my branch? This will now contain the two code updates that my two colleagues also merged into the branch. I wasn't sure whether my branch should now also contain other updates from other team members?
Yes. Commit the changes back into the branch (so they are backed up to source control) and merge the changes back into main. The aim is to ensure the merge back into trunk disrupts the team as little as possible. You can test your application off the branch beforehand to ensure all the changes are working as intended and there are no bugs created inadvertently.
Upvotes: 2