ClearCase和SCCS

Clearcase中每个元素的版本可以看成是这个元素的一个snapshot。它包含了上一个版本的内容以及这个版本所引入的变化(delta)。说它是一个snapshot是因为它本身不含有任何变化信息。只有通过和前一个版本比较才能够得出这个版本所引入的delta。而且每个版本对应于一次check-in操作。它只会归属于一个activity。如果一个activity在一个branch上check-in多次，则它会产生多个版本。当我们用cleartool diff命令来显示一个activity的所做的修改时，Clearcase实际上是将这个activity所关联的最后一个版本和它的第一个版本的前一个版本进行比较。如果在这个activity最后一次check-in之前，有其他的activity也check-in了code，那么这个比较将会显示出那个activity引入的修改。如果我想用我最后check-in的版本来编译链接产品，不可避免地将其他人的改动引入了进来。这造成了多人在同一个stream/branch上开发的相互影响。这个似乎在Clearcase中无法解决。只能要求将各个activity隔离在不同的stream/branch中进行修改。

SCCS则和Clearcase不同。它同时记录这个元素的baseline和各个改动的delta。当你check-out这个元素时，它将baseline和之前check-in的改动合并在一起形成这个元素的最新的版本，当你修改完后check-in是它不是记录修改后的最新版本内容，而是记录这次修改的变化，其实就是添加或者删除的内容，修改可以看成是删除加上添加。这个变化和这次check-in的activity(SCCS中称为MR)关联起来。当你用一个MR多次check-in不同的修改，所有的改动都是和这个MR关联的。当有多个人同时修改这个元素时，个人的改动都和他们自己的MR相关联。当我们check-out时，这个最新版本不仅包含我的改动，也包含了别人的改动。这样我就可以尽早地发现和解决不同人改动的conflict。但当我们想用用最新版本来编译链接产品时，我们想要的baseline加上自己的修改，而不要包含别人的改动，此时需要用getversion来获取和一个或者多个MR向关联的最新版本。通过记录delta的方式SCCS可以在一个stream/branch上很好的隔离各个开发人员的改动。一旦这些改动需要baseline下来，只要approve那些MR所关联的修改，那些修改就被集成到最新的baseline中。