标签：
新项目的目录结构说明：
代码分三部分
1、01_Trunk（开发主干）
2、02_Branches（开发分支）
3、03_Tags（提交代码区）
文档区
请注意SVN的路径是区分大小写的！
与VSS的区别：
1、不能单独一个文件检出，只能检出相应的目录
建议：开发人员在参与一个项目的时候，首次可以将该项目下所有资料都进行检出，一个是便于查看，另一个是保证目录结构的统一和完整性，以免提交的时候，由于目录的混乱导致提交出错；
2、将一个项目的源码复制到另一项目中时,不能直接复制,要清除那此隐藏的.SVN文件夹,最好是在SVN上使用导出功能。否则，易在提交文件时错误提交到原来项目之上。
因为导出目录的时候，SVN会在所有与配置库关联的每个文件夹下都生成一个.svn的文件夹，这个SVN的文件夹中就记录了你当前工作副本的版本号，关联的配置库路径等信息，如对整个文件夹进行复制，会将该文件夹也复制，这样，就算你拷贝到别的文件夹下，所关联的配置库信息还是原来的，提交还是会提交到原先关联的配置库路径的；
建议：尽量不要对目录进行复制，系统最好设置成，文件夹选项--查看--显示隐藏的文件和文件夹 如需要复制整个目录，有两种方法，一种是直接用 版本库浏览器进行操作，右键是可以直接复制的 具体是：选中相应的文件夹，右键—复制到 即可
3、如果该目录没有写的权限时，会在提交的时候，显示一条错误信息，看到后面的错误编码是403错误，一般是这个目录没有写的权限，需申请，呵呵；同理，如果对该目录没有读的权限，在版本库浏览器中，点击该目录，也是会出现403错误；但现在，一般如果是项目组成员的话，我都会开通各个目录的读权限的，至少给大家看的权限，呵呵
4、SVN的工作模式与VSS不同，不是采用锁定-编辑-锁定的模式，即可以多人同时检出，只在提交的时候提示冲突，要求解决冲突；
SVN使用要诀——先更新后提交
为避免频繁的解决冲突，一些经常冲突的文件，可以在提交的时候选择：保持锁定，这样别人在更新该文件到本地时，默认的文件属性是只读的；
5、用Eclipse开发需注意的事项：
.class文件夹不要提交到SVN配置库上受控，否则编译的.class中，
SVN一些容易混淆的概念解释：
1、Checkout（检出）与Export（导出）
两者都是获取文件，区别在于，check out方式获取文件后，文件处于版本控制中，而export是导出当前版本的数据，文件脱离了SVN版本控制。
2、Relocate（重定位）与Switch（切换）
如果你的版本库移动了，或许是因为移动到了一个新的目录，或者是域名改变，你需要“relocate”你的工作副本，这样你的版本库URL指向新的地址，这种情况下，是版本库本身移动了；
如果要在同一个版本库中切换一个分支或目录，就需要执行Switch操作。当主干和分支只有微小差别时，这个命令非常有用，你可以在目录之间跳转，而只会有很小区别需要传输。
3、Delete（删除）
删除文件要使用“TortoiseSVN—Delete”进行删除，一定不要直接删除（对于重命名、移动文件或文件夹也是一样，要使用TortoiseSVN的菜单进行这些操作，否则之前的版本信息会丢失。）；文件被删除后，该文件的所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。
4、Commit（提交）
进行了任何修改后，通过Commit操作可以将修改提交到服务器的版本仓库中。在工作复本的文件夹的空白处点击鼠标右键和选中当前目录执行提交的效果一样；
提交文件要慎重，尽量不要提交不需要或不能提交的文件，包括以下几类文件：
Ø 临时文件*tmp、垃圾文件：为了避免提交这类文件，就尽量不要直接Commit，选择全部文件提交，而是先执行Add操作选择需要添加的文件，这适合提交文件数目较少的情况，当然，如果你的电脑设置的可以显示这类隐藏文件，你就直接删了它们，以除后患，如果你有定期清理电脑垃圾文件的习惯，这类文件就自然会被清理掉；
Ø 编译器产生的文件，例如*.obj，生成的二进制文件等，常有些同事不注意把Debug和Release目录都Commit了！其实，“TortoiseSVN—Settings—General”中有一个设置“Global ignore pattern”（全局忽略模式），通过在模式框中输入文件名或扩展名就可以在提交时忽略这些文件或文件夹。不同的模式之间以空格分隔，例如*/bin */obj *.bak *.~?? *.jar *.[Tt]mp；
Ø 病毒文件：在实际中，真的碰到有同事把病毒文件都提交到SVN版本库中了，这不是害人吗，因此首先要养成定期杀毒的良好习惯，其次在提交时一定不要一股脑全盘提交！
提交文件还要养成以下良好习惯：
Ø 提交时一定要写备注，而且要写有意义的备注。备注有助于人（包括三个月后的你自己）理解你对文件所做的修改；其次在检出历史版本时，清晰的日志有助于快速查找到自己所需要的版本；
Ø 把握Commit的频率。不能太频繁，每修改一个小小的地方就提交，则会产生很多版本；而隔时间太久再提交，则其他相关人员不能及时获取你的改动，在提交时就容易造成冲突；当然，要视团队的具体情况而定了。
Ø 在多人协作时，尽量修改自己撰写的部分，不要修改其他部分；这就要看团队协作的能力了。
5、Update（更新）
Update对不同的人所做的修改会自动合并，如果无法自动合并则会发生冲突，需要手工用文件比较工具进行合并；因此要注意经常更新自己的工作复本，以保证自己能够获得最新的修改内容，降低发生冲突的可能性；
要养成提交前先更新的好习惯，如果没有更新就提交，很有可能提交失败；另外，有时候会需要通过复制文件的方式覆盖本地的同名文件，间接的修改文件然后再提交，进行这种操作一定要慎重，如果此时服务器上的文件版本相对于你复制的文件已经修改了某些BUG，这样提交后，以前修复的BUG就又会重现！
6、Revert（撤销）
如果进行了修改，但没有执行Commit操作，如果这时候想放弃这些操作，就可以通过Revert操作更新到修改之前的版本。
如果你想看看先前的某个版本是什么样子，可以通过“TortoiseSVN—Update to reversion”，回退到选择的版本。或者“show log”，选择某个版本，在右键菜单中选择“Browser repository”，查看选择的版本。
在实际操作中，有时需要回退到某一个版本，但是在这个过程中可能有一些文件你想保留，也有一些文件你不想保留，这种情况下推荐的做法是：export你所需要的文件版本，覆盖当前的文件，这样就可以同时保留先前的文件和现在新建的文件。
标签：
原文地址：http://www.cnblogs.com/seer/p/4206091.html
