我们在本地创建的文件(包括目录)不会受SVN的控制，为了让其接受SVN的控制必须将其添加到文件库中。对于团队其他成员需要的文件，如代码文件、某些模块的.a文件（由于某些需要，该模块代码不公开），我们必须让它们接受SVN的控制，并且保持最新的版本。
4.3 文件删除
当我们需要删除无用的文件(包括目录)时，不能使用Windows的资源管理工具，而必须使用SVN本身的删除文件功能。这样该文件被删除后，其所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。
4.4 文件改名
当我们需要对文件(包括目录)进行改名的时，不能使用Windows的资源管理工具，而必须使用SVN本身的文件改名功能。这样该文件被改名后，其改名前的所有修改历史仍然保存在SVN服务器中，保持连续的修改信息。
4.5 文件更新
其他团队成员提交到SVN上的改动不会自动更新到你的本地拷贝中来，我们需要通过更新文件操作来获取其他成员对项目文件所做的修改。SVN更新文件操作会把文件库里的��件与本地文件进行合并，从而达到了同时保留其他成员的修改及本地的修改的目的。如果无法自动合并则会发生冲突，需要使用文件比较工具进行手工合并，合并完成后才能提交已解决冲突的文件。冲突的详细解决方法见第三章——冲突解决。 在团队开发时，更新是一件很重要的工作，可以保持团队成员之间的工作内容一致，因此要注意经常更新自己的工作拷贝，以保证自己能够获得最新的修改内容。 4.6 改动提交
我们对文件(包括目录)所做的一切改动，包括添加、删除、修改文件都必须提交到SVN服务器文件库中才能正式生效，之后团队的其他成员才可以获取你所作的修改。
提交是很重要的一项操作，要求做到：
1)提交代码之前一定要保证修改后的代码能编译通过，不能提交编译不通过的代码。 比较修改前及修改后的代码，把调试信息或其他不相关的信息去掉，再次确保提交的代码是
正确的并且提交的是需要提交的文件。
2) 不要等到修改了很多代码才提交，而是相关小功能完成时就应该提交一次。这样以后发现问
题时就很容易撤销有问题的代码——因为撤销只能针对一次提交，所以在一次提交里涉及过多的功能是不推荐的。
3) 提交时必须填写log信息，说明这次提交增加了什么功能或者修正了什么bug。这些信息有助
于自己和其他团队成员了解整个项目的历史。当出现问题时也方便定位到对应的版本代码，所以log信息必须足够详细。
4) 事务性提交。也就是说提交要么成功，要么全部失败——即提交出现错误时会自动回滚，实
际上没有提交任何东西。出现错误时，解决错误，再次提交上次提交的全部内容即可。
附录：测试自动化小组SVN使用指导原则
1.Project的构建
Project在SVN服务器上的目录架构如下：
SVN上的项目文件：
1. 必须保证Trunk上的代码是最新的！定期对Trunk上的代码进行更新，各小组可根据各自实际
情况自己把握
2. Tag是根据项目需要所打的标签，每一个发布的版本都要打Tag，主要是方便有需要时可以
直接根据Tag返回到之前的状态，以便于分析、测试；Tag中必须包含相应的release文件及当时编译或发布时的源代码，必须有相关的文档注明项目背景、发布情况等。
3. Branch文件夹可以用作备份用，可以用个人名字命名文件夹；此外，Branch分支主要用来
进行短暂或者探索性的开发使用，最终的软件版本必须更新、合并到Trunk主干上。 4. 关于同一项目组开发环境的建议：同一项目组成员的开发环境最好一致，软件安装路径和
Project文件存放路径最好一致。
2. 版本号
关于版本号命名规则：主版本号.子版本号.修正版本号
1. 项目初版本时，版本号为0.1.0；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位
为 0；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号
加 1，子版本号和修正版本号复位为0；
5. 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，如果编译器不能自
动生成，人手添加，数值代表为当前的系统时间。 例子：V1.0.1 Build090305 Rel111123 其它版本使用规则： 1. α（alphal）内部测试版
此版本表示该软件仅仅是一个初步完成品，只在组内内部交流，该版本软件的 bug 较多，限内部测试使用。
例子：V0.1.1 Build090305 alphal1 2. β（beta）外部测试版