Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>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.</p> </blockquote> <p>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 <a href="http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-repobrowser.html" rel="nofollow noreferrer">http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-repobrowser.html</a> for more information.</p> <blockquote> <p>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?</p> </blockquote> <p>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.</p> <p>[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.</p> <blockquote> <p>Question - once I have released the changes should I be creating another tag Version 1.1/2.0 etc?</p> </blockquote> <p>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 <a href="https://stackoverflow.com/questions/372321/best-practice-for-svn-tags">Best practice for SVN tags?</a>. </p> <p>[Edit: Added]</p> <blockquote> <p>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 <strong>do I commit everything back into my branch</strong>? 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?</p> </blockquote> <p>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload