转换就像更新一样，不会丢掉本地的任何修改，而是将未提交修改合并。如果不想这样，那就在转换（switch）之前进行提交（commit）操作，或恢复（revert）副本到某个已提交版本（一般都选head版本）。 图4.20. 转换窗口
Subversion是不明白tags与branches的不同的。下面列出几点区别：
1． 标记用于创建项目在一个特殊阶段的静态快照，通常不再用于开发，而分支是用于开发的。这就是先前推荐使用/trunk /branches /tags结构的理由。当然你也可以修改/tags/中的副本，但提交时TortoiseSVN会有警告。
2． 如果一个已经标记过的还发布了的版本，还要进行修改，正确的方法是创建一个新的分支，在新分支上做修改，再根据这个分支创建新标记。比如Version_1.0.1。 3． 如果在副本上修改并提交，则修改只体现在分支上而不是主干上。 4.17. 合并Merging
Where branches are used to maintain separate lines of development, at some stage you will want to merge the changes made on one branch back into the trunk, or vice versa.
在进行合并操作之前，理解subversion中分支与合并如何工作是蛮重要的，否则可能导致很复杂的情况出现。强烈建议各位去阅读Subversion Book的Branching and Merging这一节，那里有详细的描述和很多例子。
There are two common use cases for merging which are handled in slightly different ways, as described below.
4.17.1. Merging a Range of Revisions
This method covers the case when you have made one or more revisions to a branch (or to the trunk) and you want to port those changes across to a different branch. Figure 4.21. The Merge Dialog
To merge revisions you need to go to a working copy of the branch in which you want to receive the changes, often the trunk. Select Merge... from the context menu.
In the From: field enter the full folder url of the branch or tag containing the changes you want to port into your working copy. You may also click ... to browse the repository and find the desired branch.
Because you are porting a range of revisions from the same branch into your working copy, make sure the Use \
In the From Revision field enter the initial revision number. This is the revision before the changes you want to merge. Revision numbers are auto-incremented after each commit. You want to start merging the changes before the revision number is auto-incremented. For example, if your log messages look something like this:
Rev Comments
39. Working on MyBranch 38. Working on trunk 37. Working on MyBranch 36. Create branch MyBranch 35. Working on trunk 34. Working on trunk ...
If you now want to merge the changes from MyBranch into the trunk you have to choose 36 as the From Revision. Not 37 as you might think.
The easiest way to find the revision you need is to click on Show Log, as this will list recent changes with their log comments. Select the revision you require in the Show Log dialog, then click on OK.
In the To Revision field enter the last revision number in the range you want to merge. Often this will be the HEAD revision, although it doesn't need to be - you can just want to merge a single revision. Click OK to complete the merge.
The merge is now complete. It's a good idea to have a look at the merge and see if it's as expected. Merging is usually quite complicated. Conflicts often arise if the branch has drifted far from the trunk.
When you have tested the changes and come to commit this revision, your commit log message should always include the revision numbers which have been ported in the merge. If you want to apply another merge at a later time you will need to know what you have already merged, as you do not want to port a change more than once. Unfortunately merge information is not stored by Subversion. For more information about this, refer to Tracking Merges Manually in the Subversion Book
If you want to keep this branch up to date with the trunk, you should immediately merge changes from trunk back to the this branch. Use this method and local changes won't get in your way. Of course, you should still avoid repeated merging of trunk changes, as explained above.
If you want to see what changes will be made by a merge and see where possible conflicts may occur you can check the option Dry Run . This will force the merge command to do a merge, but not modify the working copy at all. Important
Subversion can't merge a file with a folder and vice versa - only folders to folders and files to files. If you click on a file and open up the merge dialog, then you have to give a path to a file in that dialog. If you select a folder and bring up the dialog, then you must specify a folder url for the merge.
4.17.2. Merging Two Different Trees
This method covers the case when you have made a feature branch as discussed in the Subversion book. All trunk changes have been ported to the feature branch, week by week, and now the feature is complete you want to merge it back into the trunk. Because you have kept the feature branch synchronized with the trunk, the latest versions of branch and trunk will be absolutely identical except for your
branch changes. So in this special case, you would merge by comparing the branch with the trunk.
To merge the feature branch back into the trunk you need to go to a working copy of the trunk. Select Merge... from the context menu.
In the From: field enter the full folder url of the trunk. This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes. You may also click ... to browse the repository.
Because you are comparing two different trees, make sure the Use \checkbox is not checked.
In the To: field enter the full folder url of the feature branch.
In both the From Revision field and the To Revision field, enter the last revision number at which the two trees were synchronized. If you are sure no-one else is making commits you can use the HEAD revision in both cases. If there is a chance that someone else may have made a commit since that synchronization, use the specific revision number to avoid losing more recent commits. Click OK to complete the merge.
In this case you will not need the feature branch again because the new feature is now integrated into the trunk. The feature branch is redundant and can be deleted from the repository if required.
4.18. 创建和应用补丁Creating and Applying Patches
如果谁都可以随便修改，项目将没完没了，永远没法稳定下来。怎么办呢？通过“补丁patch”！将补丁送交给具有写权限的开发团队，他们先审查补丁，再决定是否提交，或者打回给作者。 补丁文件只保存有副本与基础版本的差异。
4.18.1. Creating a Patch File
First you need to make and test your changes. Then instead of using Commit... on the parent folder, you select Create Patch... This will produce a single file containing a summary of all the changes you have made since the last update from the repository. If you create a patch file, make some more changes and then create another patch, the second patch file will include both sets of changes.
Just save the file using a filename of your choice. Patch files can have any extension you like, but by convention they should use the .patch or .diff extension. You are now ready to submit your patch file.
4.18.2. Applying a Patch File
Patch files are applied to your working copy. This should be done from the same folder level as was used to create the patch. If you are not sure what this is, just look
at the first line of the patch file. For example, if the first file being worked on was doc/source/english/chapter1.xml and the first line in the patchfile is Index: english/chapter1.xml then you need to apply the patch to the english folder. In order to apply a patch file to your working copy, you need to have at least read access to the repository. The reason for this is that the merge program must reference the changes back to the revision against which they were made by the remote developer.
From the context menu for that folder, click on Apply Patch... This will bring up a file open dialog allowing you to select the patch file to apply. By default only .patch or .diff files are shown, but you can opt for \
TortoiseMerge runs to merge the changes from the patch file with your working copy. A small window lists the files which have been changed. Double click on each one in turn, review the changes and save the merged files.
The remote developer's patch has now been applied to your working copy, so you need to commit to allow everyone else to access the changes from the repository. 4.19. 副本重定位Relocating a working copy Figure 4.22. The Relocate Dialog
If your repository has for some reason changed it's location (IP/URL). Maybe you're even stuck and can't commit and you don't want to checkout your working copy again from the new location and to move all your changed data back into the new working copy, relocate is the command you are looking for. It basically does very little: it scans all \to the new value. Warning
Don't use the relocate command to switch your working copy to a different branch! If you do that, then you will get many unexplainable error messages while updating, committing, ...
The relocate command must only be used if the URL of the server changed!