关于VS2010+SVN多人协同开发的问题
背景：采用VS2010+SVN多人协同开发，asp.net项目。环境已配置完成，可以实现文件check in和check out。
问题：
多人如何测试？目前想到的方案是各人单独在自己的PC上开发、编译、调试，完成之后再update到SVN服务器，大家分别获取更新到本地。
有没有可能大家一起在一个站点上编译、调试？比如服务器上，还是说只能在自己各自的IIS站点上进行调试？
或者换句话说，大家是怎么协同开发的？包括写代码、怎么check in/out、怎么调试等，希望能描述的详细一些。
只能给到百分，分不够再加，不甚感谢！
[解决办法]
建议你用tfs，它是一个完整的解决方案。你可以保留svn，但是把测试管理、跟踪工作项、反馈管理、自动集成交给tfs。
[解决办法]
当然最好是全部都用tfs。
tfs的好处在于，你可以使用它的生成服务，当用户提交代码，自动会跑测试，然后通知你。
tfs还支持code review，A测试人员发现了问题，可以像bbs评论一样添加意见，然后自动发给B程序员，程序员可以挂起当前的工作来修补bug。
这个视频演示了这个场景：
http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-Using-Code-Review-to-Improve-Quality
[解决办法]
SVN以前我也用过了,那时候版本比较低,有时候存在更新不到最新版本,现在应该更完善了吧.
目前我们用的是VSS,很少看到有出错,觉得还OK.
-------->有没有可能大家一起在一个站点上编译、调试？比如服务器上，还是说只能在自己各自的IIS站点上进行调试？
最新代码都在服务器上,谁都可以调试,你用SVN也是可以的
关键的一点是:要即时把最新版本check in到服务器,又从服务器上获取最新代码.保证每一次check in时不能有编译报错.
[解决办法]
给你搜了一下，查到这个文章，可以参考 http://www.admin10000.com/document/1316.html
使用SVN，首先一点重要的原因，是我们修改文件的时候是处于“断网”和移动状态，而不需要联网。仅仅当你Update/Commit的时候才需要联网。
于是，我们可以放心地回家写代码，可以去茶馆写代码，可以随时移动到未知的环境。在多人合作开发时，不至于因为网络出现（太容易出现的）一点问题而让许多人找到“干脆出去去逛街”的理由。于是我们可以轻松地让相隔几千公里的多个办公室的多个同事，比较自由地使用SVN，而冲突远远小于那些动不动就用网络给文件“上锁”（反过来说，动不动就给团队协同带来加锁灾难）的源代码管理系统。
任何人的开发和自动测试，当然都是在它的本地进行的。就算是用户，也得在自己的电脑上使用网络软件客户端。而处于开发中的小系统，就算是分为“服务器端、客户端”，由于频繁修改（一天需要Update十几回），那么往往在开发人员的机器上同时有服务器程序和客户程序，本地的程序访问本地的服务器程序。
软件开发中的质量保证，这需要基本的训练。一个人应该把问题缩小到一个小时的工作量，才应该开始动手写代码。那种脑子里只有持续好几天才能搞定（反过来也就是说一个小时内肯定搞不定）的事情人，是一种非常“混沌”的人，或者说是有些幼稚的人，他还没有把一个任务分解为眼前的几个“一个小时”的任务，就胡乱开始动手做了。
养成好的软件开发习惯之后，很自然地就可以接受敏捷开发的一个基本要求——频繁地发布代码。一般来说你可以每隔10分钟、20分钟就向svn提交一次代码。当然这没有什么特定的空洞规定，但是这种参考可以提示你实际倾向。不是每天只提交两三次，而是频繁地提交！
当然前提至少是你的代码可以完全正确地编译通过并且稍微手工测试一下局部内容，可以通过之后，才提交到svn。
源代码管理系统就是一个工具，他不能代替一个团队人员的协同开发的水平。如果人人都“埋头苦干”地写代码，那么这很可能就是一个坑爹的团队。好的团队会经常交头接耳甚至两个人公用一个显示器（但是不是谈论那些“损友、长舌妇”式的话题）；不是大家都按照中等偏低水平的人所理解的什么“增删改查、三层开发”的空洞方式，而是有各种引擎、协同插件开发，因此每个人每天都要把自己的某个功能给别人发布和测试（改错）好多次。因此SVN不但给自己保存了代码版本，而且也是代码发布的工具。关键是看人的协作的水平高一些，才能用好SVN。
一个好的敏捷开发团队，可不是那种很垃圾的软件作坊。因此不存在什么“代码归个人所有”的习惯，而是鼓励“任何人都可以随时修改别人的代码，可以提交修改，可以尽快响应bug问题”。并且基本上不会带着bug去进行开发，一旦有了bug就会停下开发进度，先解决了眼前的bug才继续开发。而这个的前提条件，就是要有非常敏捷的测试手段，随时发现bug，每天对代码进行上千次、上万次地回归测试。
而这种高强度进行代码提交和修改的手段，如果没有svn（或者更好的网络软件）是不可想象的。你可以相像vss那种“加锁修改”的方式，就好像是给每一个汽车都拴上一根输油管连到加油站（而并不是给汽车装上一个大油箱让其自由地奔跑），因此非常不方便。而使用SVN，首先一点重要的原因，是我们修改文件的时候是处于“断网”和移动状态，而不需要联网。
[解决办法]
随便写了一点点滴经验，没想到会写这么多！实际上用好它，不仅仅是知道这个工具如何如何，还要基于非常好团队工程经验。
[解决办法]
呵呵，我只是随便“瞄了一眼”那个文章，就推荐参考了。对于以下两点我认为不妥：
1. 第一条，它因为vss比较老旧说它不适合了，这个言之无物。vss是因为技术原因而不适合，不是因为比较老。
2. 对于第五条（每一次提交时都写上一行注释），实际上这个要求一个人提交代码的“计划”过于细碎。实际上我们提交时可以“无目的”的，也就是一旦我们意识到超过10分钟没有提交过，并且当前的程序（以及源代码中的测试工程）可以编译通过，并且简单跑过一次最近3天的测试，那么我们就可以提交。此时我们可以写也可以不写注释。因为我们提交时大多数时候就不是死抠某一个功能点的问题。我们要看某个功能被谁修改过了，我们会看svn上的当前文件的修改的History，并且使用svn的自动比较源代码功能，也就是说我们看源代码，而不看文章中的那个东西。（注意到，由于频繁提交，因此每一个版本针对某个文件，往往仅仅修改了很少的几行代码而已）
[解决办法]
