Perforce学习心得
软件配置管理(SCM)是一款构建于可伸缩客户/服务器结构之上的软件配置管理工具。SCM管理源码并保持其安全的良好艺术，它能实现源码与其他团队成员之间保持共享，并且能够对之加以保护。良好地利用SCM，你能够容易地跟踪软件的发行和新的开发分支；这样以来，可以更为容易地标识和修正发行产品中的错误。仅仅应用TCP/IP，开发人员就能够通过多种Perforce客户端（几种平台的GUI、WEB、或命令行）访问Perforce服务器。Perforce能够被快速和容易地部署，即使对大型或分布式的站点，也只要求最小限度的管理。Perforce可以使用在50多个操作系统中，它包括版本控制、工作空间管理、变更处理和一个强大的分支模型。
版本控制的功能：跟踪记录整个软件的开发过程，包括软件本身和相关文档（所带来的结果是：可标识不同阶段的软件及相关文档，进行差别分析；对软件进行可撤消的修改；便于汇总不同人员所做的修改），辅助协调和管理软件开发团
1 软件代码的一致性
软件的开发、维护和升级，往往是多个人共同协作的过程。不同人对同一个软件的不同部分同时做着修改，这种行为有时会出现彼此交叉的情况。由于同一软件在各自开发人员的机器上都有拷贝，软件的全部代码都暴露在每个开发人员面前，原则上他有权限可以不加限制地更改软件的任何部分。而当他们修改的内容属于公共部分，或者需要被其他人员所负责的部分调用时（软件各模块间的彼此依赖关系决定了这种情况是经常发生的），这种修改就属于交叉情况。此时，就有可能出现代码的不一致现象。比如：修改者在改动了某个公共函数的同时也修改了其调用接口，若其他人员没有得知此事，而在各自机器上仍调用原来版本的函数，则当整合时，就会出现错误。另一种更为严重的情况是，修改者决定废弃原有函数而另外编写一个新的函数，但他并未删除原有函数，这种情况即使最后的整合也可能不会被察觉，如果将这种一致性错误的纠正延迟到测试阶段，则会增加调试的难度，从而降低开发效率。为了始终保证代码的一致性，一种解决办法是，要求修改者每次修改后都通过某种方式告知同组其他人员，或者随时对软件做整合。但是这样，一方面会增加开发人员的负担，另一方面也降低了软件的开发效率。
2 软件开发的“并发性”
由于是多人共同开发一个软件，期间出现多人修改软件的同一部分，尤其是同时修改，有时是不可避免的。对于前者，具有良好编程习惯的人员的一种通常做法是，对他人的源程序进行修改时添加必要的注释，写明修改人，修改原因，修改日期等。但实际情况是，当修改内容很零散或修改过程很复杂时，注释很难写，或者代码被注释分割得支离破碎影响正常阅读，或者注释无法详细说明实际情况。而且，这种做法也增加了开发人员的负担：他需要在考虑代码逻辑的同时，兼顾如何写注释；而对于注释和代码的一致性也是他需要随时留意的问题，不能疏忽。因此，我认为这种措施在实际开发中，并未取得实质效果，是不必要的，事实上代码本身（而非注释）是最能说明问题的，而修改的记录应该置于代码之外的某处。而且，不论是否是同时修改，都需要考虑1所提到的一致性问题，需要及时进行人工的差异比较和整合以便形成一个统一的新
3 软件代码的安全性
由于代码完全暴露于所有开发人员面前，任何人都可以增、删、改之。除了会造成1所提到的不一致问题外，从安全的角度来看，也是存在隐患的，这一点对于一个自主产权的长期开发的产品而言更是如此。即使是一般的项目开发，不同的人员其分工不同，允许别人可以不加限制地任意修改自己负责模块的代码（相当于所有人员都具有管理员身份），总是容易产生问题。对于共有模块更是如此，所有人都可以修改，一旦修改，则波及全体。
4 手工修改文件的只读标记
为了防止你对没有签出的文件进行修改，版本控制管理工具会将这些文件指定并标明为只读文件。当你签出一个文件时，只读标记便被删去。一种经常出现的不良习惯是，为了图省事，在没有签出文件时便试图修改文件，当发现文件不能保存时，便手工修改其只读标记。这是一切混乱的“源头”，它将导致不一致、有效内容被覆盖等问题。
5 多人修改同一个文件
一旦出现这样的情况，很有可能某人辛勤劳动的成果，会被别人毁于一旦。其解决办法是：在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。为了适应多人同时修改同一个文件的情况，版本控制管理员也可以改变此缺省设置以允许对单个文件同时有多个签出（checkout），并且仍禁止对他人的修改进行覆盖。
6 用户权限混乱
对于所有开发人员和各自负责的模块，根据实际情况，制定合理的用户权限，哪些人对哪些目录只有可读权限，哪些人对哪些目录有读写权限。不应该出现所有人都是管理员这样的极端情况。
扫一扫
996
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
