VS中使用svn注意事项

一、程序需按期编译经过后上传SVN，天天可上传屡次，根据我的程序开发进度决定，但天天晚下班前必须将当天的程序编译调试经过并上传SVN。天天早上上班首先须要更新SVN最新版本。 

上传的工做流程应该是，更新——编译运行——上传。这个工做流程那一步也不能缺乏。更新是在把 别人提交的代码下载下来，看看和本身所写的代码有没有什么冲突，可能本身须要用到的一个函数已经被别人所修改。致使本身原本运行完美的系统出现了错误。如 果没有编译运行就上传了。别人下载下来的代码就是错的了。这样经过几个版本的迭代。出现的错误就很难被发现与纠正。这就又产生了一个原则：任什么时候候不能把错误的代码往服务器上传。对于屡次上传，主要目的是把损失下降到最低，这样一旦出现了错误恢复上一个版本的损失才会最少。但天天晚下班前必须将当天的程序编译调试经过并上传SVN。对于这一点有两个重要意义：1.天天老板都知道你今天干了多少活。2.把今天的工做告一段落，没有压力的开始明天的工做。明天其余人的任何更改都不会影响你今天的工做。

 

二、在程序中添加页面、删除页面及修改页面命名时，须要先更新所有程序特别是解决方案文件，而后再作添加或者删除页面以及修改页面名称，作完这类操做后需马上上传SVN，以避免形成解决方案冲突 

先说什么是解决方案冲突：

csproj文件你们应该不会陌生，那就是C#项目文件的扩展名，它是“CSharp Project”的缩写。那么它到底是给谁用的呢？那是给开发工具用的，例如咱们在熟悉不过的VisualStudio，以及你们能够没有接触过，可是应 该都据说过的MSBuild.exe。VisualStudio会根据csproj里的XML定义来管理项目文件以及相关其余一些种类很是丰富的数据及操 做，MSBuild也会根据csproj文件来得知编译这个项目须要有哪些依赖，默认输出路径，Pre-Build和Post-Build须要哪些操做等 等。VisualStudio和MSBuild都是开发工具，这就是csproj存在的惟一意义：为“开发环境”提供信息。而到了运行环境中，根本不会有 人（操做系统？）关心所谓的csproj文件——也就是“程序是哪里来的”。

了解了csproj文件也就能理解什么是解决方案冲突了。你在程序中添加页面、删除页面及修改页面命名时都是须要修改这个管“程序是哪里来的”的这个文件的。这样若是你下载下来添加了页面，而后提交了。他也下载下来而后也提交，是必定会出现版本冲突的。（固然以上原则不仅是添加页面时，添加类也是同样的。）这个时候技巧2，就显得尤其重要了。 

 

3.如下文件不容许提交到SVN上，应在本地经过SVN客户端添加到忽略列表中。

一、解决方案的suo文件

二、工程的bin文件夹和obj文 

这些又是什么文件呢? 

suo文件 

suo(solution useroptions)是一种文件的格式。*.suo解决方案用户选项，记录全部将与解决方案创建关联的选项，以便在每次打开时，它都包含用户所作的自定义设置。好比VS布局以及项目最后编译的而又没有关掉的文件用于下次打开时用。

其中，VS布局包括：监视器1234的变量列表、断点标记及开关状态、输出窗口错误窗口等的分布及其悬浮状态，还有项目卸载状态标记。

.suo文件偶尔会被破坏，从而在构建和编辑应用程序时出现意想不到的结果。若是VisualStudio对于每一个解决方案不稳定，就应删除.suo文件。下次打开解决方案时，Visual Studio会重建它。

 

bin和obj文件夹 

bin是放最终代码的目录

obj就放中间代码的目录

Bin目录用来保存项目生成后程序集，它有Debug和Release两个版本，分别对应的文件夹为bin/Debug和bin/Release，这个文件夹是默认的输出路径，咱们能够经过：项目属性—>配置属性—>输出路径来修改。

obj目录是用来保存每一个模块的编译结果，在.NET中，编译是分模块进行的，编译整个完成后会合并为一个.DLL或.EXE保存到bin目录下。由于每次编译时默认都是采用增量编译，即只从新编译改变了的模块，obj保存每一个模块的编译结果，用来加快编译速度。是否采用增量编译，能够经过：项目属性—>配置属性—>高级—>增量编译来设置。

能够看出这些文件都是根据本地的信息产生的配置文件，每一个人和每一个人的均可能是不同的。因此上传的时候应该屏蔽。等到本身更新了最新版本。从新编译，就会自动的产生可使用的本身的配置文件了。

 

这些技巧更应该说是咱们要培养的工做习惯，只用有了这些工做习惯咱们的合做开发才会更加的愉快，更加的和谐。

---

先更新，再提交 
SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，可以经过编译而且本身测试以后，谨慎地提交。 
如 果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。若是别人和自 己更改的是同一个文件，那么update时会自动进行合并，若是修改的是同一行，那么合并时会产生冲突，这种状况就须要同以前的开发人员联系，两我的一块儿 协商解决冲突，解决冲突以后，须要两人一块儿测试保证解决冲突以后，程序不会影响其余功能。 
在更新时注意所更新文件的列表，若是提交过程当中产生了更新，则也是须要从新编译而且完成本身的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误致使代码有错。

 

多提交 
每次提交的间歇尽量地短，以几个小时的开发工做为宜。例如在更改UI界面的时候，能够每完成一个UI界面的修改或者设计，就提交 一次。在开发功能模块的时候，能够每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug而且确认修改了这个bug，也就提交 一次。咱们提倡多提交，也就能多为代码添加上保险。

不要提交不能经过编译的代码 
代码在提交以前，首先要确认本身可以在本地编译。若是在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工做区域的时候，须要考虑到这样的状况，确保开发小组成员在签出代码以后可以在统一的环境中进行编译。

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

提交时注意不要提交本地自动生成的文件 
例如eclipse中的.classpath文 件，Windows生成的缩略图Thumbs.db，项目编译生成的临时文件.obj, .class等等。若是项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地 的环境冲突从而影响你们的工做。

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

慎用锁定功能 在项目中要慎用锁定的功能，在你锁定了一个文件以后别人就没法继续修改提交该文件，虽然能够减小冲突的发生率，可是可能会影响项目组中其余人员的工做。平时只有在编辑那些没法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操做。