[转]svn在.net项目中的使用心得

1.建立svn库的时候可以选择服务器方式和文件系统方式，如果在自己用一般用文件系统方式就好了，可以避免别人下载代码。如果几个人一起用就开放服务器方式，需要安装一下subversion服务器。密码在conf/passwd里面。
2.使用svn要首先import代码，然后checkout一份workcopy。原来的代码就可以不用了
3.checkin和import的时候一定要看清楚，不要把bin，obj文件夹，.suo文件等checkin，因为这些文件是2进制文件，对我们来说做版本控制一般是没用的，而且每次编译都会改变，大部分情况下没必要做版本控制。不需要的文件add to igore list
4.一般建库的时候src文件夹下面有trunk, branches, tags三个文件夹，这个是我前几天刚知道的，怪不得从sourceforge上面下代码一般都是/trunk结尾的目录。trunk是主干代码，branch是分支代码，比如你主干代码莫个大功能还没做好，或者之前发布的某个版本有bug而客户需要修正，那就放在branches里面。tag里面一般就是tag过的版本，通常就是莫个发布版
5.checkin第一守则，必须代码要可编译。否则别人checkout以后就无法编译了。所以checkin之后一定要看一下自己的workcopy是否还是未提交的改动，这些改动是否影响主干代码的可编译性
6.尽量控制版本库的变化，就是说每次提交的粒度，我推荐是一个功能，也就是说每实现一个功能提交一次。这样子log比较好填
7.log一定要填。否则跟用压缩工具打包代码备份一样的效果。有了log才知道自己每个version是做了什么工作，那么revert到这个版本才有意义
8.不要躲避冲突。合作开发冲突是难免的。conflict出现的时候要面对它，解决它，这才是svn的真谛。tortoiseSVN的diff工具挺好的，解决冲突比较方便，我一般的方法是，用diff处理conflict，打开项目编译一遍，再验证一边没问题就可以提交了。
9.冲突出现的地方：解决方案文件，工程文件，公共模块部分，一般很少修改别人的代码文件

以上是我一段时间使用svn的一些心得吧，欢迎大家来喷~

①提交之前先更新，负责而谨慎地提交自己的代码
　　1.SVN更新的原则是要及时更新，及时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，尽量早的提交，这样也保存了历史版本，必要时候可以回滚；在开始一天的工作之前，最好update一下项目。
　　2.如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自 己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
　　3.在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错

②保持原子提交(不要不经意间修改并提交了别人的文件)

每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。当完成一个功能或文件后没有提交，后来又做了更改，结果代码出现bug，可能无法恢复到正常时的代码。
仅提交你修改的部分，最好不要一下子将整个项目提交；

③不要提交自动生成的文件

Visual Studio等开发工具在生成过程中会产生很多自动文件，如.suo等配置文件，Debug,Release,Obj等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要从仓库中删除。

④不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译。最好是代码在提交前已经通过自己的测试。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。
，
⑤不要提交自己不明白的代码

代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。

⑥提前宣布自己的工作计划(多人协作同一个模块的时候)

在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。

⑦对提交的信息采用明晰的标注(类似在代码里写的注释)

在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。

例如可以采用下列格式

+) 表示增加了功能

*) 表示对某些功能进行了更改

-) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。

b) 表示修正了具体的某个bug