如何正确使用VSS进行版本控制

前不久跳槽到现在公司，这公司主要使用VSS进行版本控制。
觉得他们使用VSS的方法不对。

如有一个多人远程不断维护的项目，有四个主要的平行的branch,
dev, test, pre-production, production。
然后每个程序员还有自己的branch（分支） 如Application1_stoneskin.

修改有几种
1. production发现的bug.
2. 新需求的项目的开发.
3. 项目QA测试时发现的bug

有时会有几个projects（项目）同时开发，一般一人负责一个，不同进度，向上合并间也不同。

现在我们是在自己的branch修复bug或进行新项目开发，完成后checkin到dev 或test. test build后给QA测试。

build系统是visual build pro, 里面分别为test, pre_production, production创建了build脚本，build好后要手工deploy的相应的server.(估计是脚本还没实现完全自动化)

我发现有几个问题
1. 看上去有3到四个主干，不断的向production合并（merge）
2. 这几个branch是不是share的，如程序员A签入到release的代码，dev分支与程序员B分支都没得到。
3. QA测试完成后，要手工合并到pre-production里，测试并被批准后，再次手工合并到production里。 pre-prodution的测试基本是被忽略的。多次合并也是非常容易出错的。更关键的是，其实 prodution的代码是没有被测试过的。因为QA的是Test分支的代码。
4. 创建分支不是以项目而是以开发者为对象。

今天同老板与同事提到这些问题，老板说是目前方法的问题他们也明白，也是经过好几次该动才成为目前情况的。让我觉得有什么建议写给报告给他。

我对版本管理也没什么经验，就是觉得目前的方法用得很痛苦。
老板说他们有意图该用svn，但觉得svn也不能完全解决问题，（好像是多个项目同时开发，当时没听明白）

请板上有经验的兄弟们指点一二正确的适合此公司的方法。
随便聊聊就行。

还有在用VSS的公司啊。赶快跳吧:)

如果branch很多，并且经常merge的话，应该转GIT 或者HG。SVN的merge也很麻烦。

换了更好的工具也还是要规范一下开发制度。
比如你说的问题3，应该直接从测试分支获得发布版本，发布成功后再合并到production

分支应该以版本为单位创建，或一系列版本为单位创建，比如1.2.x，
对于项目型的开发，分支从哪里创建的，最终还要合并回去，除非你是盒装软件，需要不断维护老版本。
svn对分支的合并支持虽然不完美，但基本够用了，只是我发现好多人根本不知道怎么用。
根据你说的“完成后checkin到dev 或test. test”，我推断，你们没有用merge功能（我不知道VSS有没有merge功能），而是采用手工copy的方式提交到多个分支的，这是很危险的。

还有，我猜测你们的测试分支根本就没有存在的必要，打tag就可以达到目的了

vss 有merge功能，但很多人用过一次后就不愿用了，
我们用一个叫beyond compare 3.0的工具手工merge

如何正确使用VSS进行版本控制 就是不使用VSS，尤其是和eclipse的结合。

你说的这个merge其实是更新。
典型的merge是 从另外一个配置库路径更新，也就是从本地工作拷贝对应的路径以外的其它路径更新，
而这个所谓的另外的路径一般指的就是分支了。
并行开发离不开分支，而分支又必须merge，所以merge是必须的功能。

vss是“悲观锁”，从根本上防止冲突，
svn是“乐观锁”，提交时才检查冲突，有冲突了才自动+手动合并，
对于大规模团队开发，显然乐观锁更好，毕竟两个人同时改了同一行代码的几率很低，
悲观锁不允许多个人同时修改同一个文件，这是无法接受的。

我们把分支间的代码移动叫merge。

VSS是可以多人同时checkout的。悲观锁只是默认值，可以修改的。很多人都不了解这点。
VSS默认是checkout后才能改文件。
你会看到有人checkout了，是个有用的功能。

谢谢你写了这么多，终于看到一个用VSS的人了。
估计是我表述不清，你没理解我的意思。

补充几点
1. 大多数项目是 c# 用VS2005/2008
2. 我们的VSS是可以多人checkout的。你可以看到那些人checkout了。
3. 我能看到所有branch上的源码。
4. 我们是维护旧的需求变化很多的系统，同时会有俩三个需求并行开发，同时produciton的bug也需要fix.
5. 需要被引用的dll统一放在SharedDlls的地方，在vss里也分别有4个projects(branch?)prod,PreProd,Testing(QA),DEV
6. 万一自己没有连上vss服务器就独自修改文件了,最常发生的情况是你的改动被覆盖了（杯具）。
7. 关于四个主干，如图示

$App1
  |---App1_Prod
  |      |-many files and folders here
  |
  |---App1_PreProd
  |
  |---App1_QA
  |
  |---App1_Dev
  |---App1_Dev_Stone
  |---App1_Dev_Mike
  |---App1_QA_John

Stone 在 App1_Dev的stone 分支开发proj1
Mike 在 App1_Dev的stone 分支开发proj2
John在 App1_QA_John分支修复bug1

Stone 每日的改动checkin到App1_Dev_Stone，完成后Merge到App1_Dev,编译通过后，将自己对App1_Dev的改动逐条update到App1_QA, app1_dev是app1_QA的branch，你可以用vss的分支merge功能，但那个太狗屎了。所以我们都选择将App1_QA的文件checkout，利用beyondCompare工具逐个update文件。
Mike与John也做类似的步骤。

QA的测试是stream式的，先到先测,但很可能测的时候proj1,proj2,bug1都checkin及编译了。测完了project1将ticket标为通过。有时proj1的错误让proj2与bug1都没法通过QA测试。

人John得到消息bug1 QA pass了，就将改动check in 到App1_PreProd. 通过一定步骤deploy到preProd 服务器上（星期2或三）。
再过一天（星期四），将改动check in 到App1_Prod， 通过一定步骤deploy到Prodtion 服务器上。

情况大致就是这样的。。

老板正考虑用Vault或Rational Team Concert代替VSS

用过vss2008再说VSS是杯具不迟，不知者不怪，但乱评就不对了。