关于vss的困惑和经验

[jackiejuju]

在vss的使用中， 经常碰到应不应该使用share的问题， 有的项目我一开始不用share， 后来用share， 最后又不用share， 感觉很头疼， 因为share不share都会有问题。 所以今天仔细总结了把， 希望大家有更好的经验：
VSS Share争议的问题之一： 如果不share不能保持项目的独立性, 如果项目中有cpp或.h不在项目的目录下而在common的目录下， 那么仅在项目上做label
的话不能保证以后拿出来的project是可以编译通过的， 因为common中的文件会变.而且common的文件也都是用于不同的多个项目的,统一做label也不合理。
VSS Share争议的问题之一：如果要复制一个包括了几个project的项目到另一个新的vss project中去电话比较困难。因为无法其中其中的复杂的share关系。
这时候不用share就比较方便。
总结: 如果不用的share的话， 一个大项目中的所有project就可以看作是一个整体, 但是子project就是不完整的, 他的历史source是很难无法编译通过的。
而用share的话， 项目中每个子project可以单独作为一个整体使用。但是share导致各个project之间的版本可能存在误差。
所以， 如果一个大项目的所有小项目一般不会单独拿出来用的话， 就不用share了, 比如ps项目中主service模块。 否则， 如果其中的几个子project会拿出来做
为单独的项目或模块用的话，也就是说独立性要求比较高的话，就用share， 以保持这个项目的完整性和相对其他平行的project的独立性。比如ps项目中的compiler
子项目， 他的历史版本单独拿出来必须是可以编译的。

有没有其他更好的使用方法?

[lanying]

严重关注！

[WEE]

采用CVS会好一点。
在CVS上做不同的BRANCH，打不同的TAG。然后结合CVSWEB，BUGZILLA和MAIL系统，可以有一个比较完整的流程。

[lanzhengpeng2]

我的用法：如果有大量的代码需要公用，就单独做成一个工程，编译成lib或dll.
少量代码我就复制两份，使用WinDiff来保证两个文件的同步

[xiaodeshi]

以我的工作经验，我提供一点参考：
如果是一个小型的开发团队，VSS是最快的，最简单的Version Control软件。在windows平台下是比较好的选择。
但如果你认为不太顺手，那还是使用CVS吧。跨平台及Version Control功能都是不受限制的。
如果我对软件工程需求不高，CVS是我的首先。
ClearCase我一直都没有机会用过，过于庞大的软件，我不太敢用。但请有ClearCase使用经验的朋友说一说自已的看法。

[july]

guanzhu

[kissfire]

密切关注！

[elpam]

我的意见：

1）VSS上也有BRANCH功能，不想SHARE的就做BRANCH吧
2）可能的情况下当然还是尽量使用SHARE

[ziben]

什么叫对软件工程需求不高,cvs 才是你的首选？
cvs可是开源世界的标准啊。

[HerbertChen]

VSS对于小型团队和刚上手的人来说，是比较好的选择

[BluePenguin]

学习

[ChaoZhang]

可是我感觉CVS有一些缺陷，比如我CheckOut了，我必须用Watch add吗，要不人家知道我在use吗，还是我得用edit呀，还有我logout我必须watch remove吗？不能自动清除吗?我是一名初学者，对于Lock我怎么用，我设置了Lock dir和start Lock service，但我在本机上用2个不同用户登录，能同时ls和Check,Why（我是在2000pro上install的cvsnt)

[housetea]

cvs本来就没有锁机制，允许多个人改一个然后合并，你check out（实际上不存在vss中的checkout定义）后人家照样能checkout这个，照样改。这是CVS和VSS的最大不同。

那样不是变得很乱

[benci26]

关注中

[passion]

cvs本来就没有锁机制，允许多个人改一个然后合并，你check out（实际上不存在vss中的checkout定义）后人家照样能checkout这个，照样改。这是CVS和VSS的最大不同。

[SteveGYCN]

问题是应该合理的设置BaseLine，这在ClearCase中是很重要的功能，非常好用（所以说它算是配置管理工具呢），它可以将一个基点上的所有文件标记成一组，可以被一起取出的、在当时可以一并编译通过的文件集，并且BaseLine的管理很直观，VSS和CVS都不能直观的具有这一概念。
我现在的做法是在VSS上使用另建一个专门的BaseLine Project，在Builder机器上将所有编译通过的文件Check In到这个Project下，工作中修改的Project和这个BaseLine Project没有直接关系，因为是在测试Builder的机器上这样做，所以绝对保证这一次CheckIn的文件是可以通过编译的，而且分离的Project也便于VSS的权限管理。这个BaseLine Project的所有文件变化应该只记录两次不同的成功编译之间的文件，而程序员修改的history保留在不同的地方，所以绝对不会有干扰的。

[july]

up

[zlyanyan]

我觉得，我们的项目VSS应该可以承受了，如果可以去考虑是用VSS还是CVS的话，到不如考虑如何把你的项目规划的更合理，

[rommy]

是上大的juweihua吧？jackiejuju?

[zxggwan123]

vss能使用web方式应用么？？如果能插件哪里能下载呢？

[jackiejuju]

谢谢各位
我觉得在一个比较复杂项目的持续开发过程中， easy是非常重要，繁琐的测试， 发布和备份过程有时候让我很恼火。
主要是下面几个过程。
1. 子项目或者说模块的更新后， 更新整个项目的过程要简单。 比如一个底层通信模块被更新后， 如果更新所有用到它的server和client。
2. 整个项目的output如果自动输出到测试环境。我现在是使用的批处理。
3. 如何自动化测试。包括集成测试和单元测试。这个我正在尝试使用dailybuilding的方法， 这个方法其实可以包括整个项目的所有自动化过程。
4. 产品备份的自动化， 产品结构比较复杂的时候， 备份是非常麻烦的， 我以前备份一次经常需要2, 3个小时。因为要从vss中去代码， 然后编译， 然后按模块标记版本号， 备份源代码和product. product不仅包括exe，dll， 也包括注册表， 配置文件， 产品帮助文档。同时也备份pdb和map文件， 有利与日后产品bug的fix。

在项目小的时候， 不需要很多这方面的考虑， 但是当一个项目到一定规模后， 不得不考虑这些东东。 如果是多人共同开发的话， 还有许多过程需要自动化， 否则， 大家一定会精疲力竭， 最后放弃编程去卖光盘了:P