Firefly进行源代码管理

现在在公司，用的是Firefly进行源代码管理，这是个国产软件，好像在金融界比较流行。但是为什么，我不清楚。以前在学校里面用的是VSS，后来看过一点点粗浅的CVS资料，现在看Firefly，觉得有点概念上的区别。无论对错，先记下来。以后还可以慢慢研究。 以软件版本管理软件的控制方法来说，主要有两种： Lock-Modify-Unlock模式，就是VSS里面的checkout，编辑，然后再checkin。checkout之后，源文件就被锁住了，其他人都不可以编辑这个文件，直到那个人再checkin，也就是提交修改同时解锁。这种模式比较安全，也很简单，但是一个文件一次只能一个人编辑，据说效率比较低。我个人却认为需要多个人同时编辑同一个文件的情况实在是太少了。 Copy-Modify-Merge模式，CVS和Firefly用的这种方式。把文件从服务器上拷贝一个副本到本地，然后编辑，这样就可以多个人同时编辑。编辑完了再上传，上传的时候再解决冲突。 因为第一种方式比较简单，所以开发机与服务器的同步比较简单，也不存在什么冲突和同步的问题。VSS的基本想法就是，在服务器上建立一些文件夹，然后把源代码放进去，不过这个结构是存在数据库里面的。客户端在必要时去读数据库，然后在本地恢复出这么一个物理文件系统。因此它面对的对象是文件和目录。 到了第二种方式，问题就复杂了，首先搞进来一个branch的东西。CVS和Firefly在这一点上似乎理解有不同。对于CVS的理解我不是很多，摘一点来源于Firefly文档的东西（http://www.hansky.com.cn/cn/resource/prod/pdf/FireflyIntro.pdf）：针对并行开发的问题，一般版本控制系统的做法是让用户直接在文件上作出一个分支（Branch），使得不同用户可以同时在文件的分支和主干上对文件进行修改，而不互相干扰，有效的起到隔离开发的作用。如图所示： 然后使用merge过程对同一个文件的不同分支进行合并，如下图： 看来，branch的出现是为了解决多用户并发修改同一文件的问题。还是上面的文档提出了这样的话：“在Firefly 中，“分支（Branch）”具有了更加合理的意义，它不再是一个文件一级的概念，而是扩展到了项目级别。我们不说“某某文件具有某某分支”，而是说“某某分支具有某某文件””。这样的话，我个人觉得，branch在Firefly里面又退回到了VSS的做法，说白了也就是“目录”。 上面的结论，是我个人的理解。目前关于Firefly的文档不齐全，而且解释也很模糊，我不敢断言这样的理解是正确的，但是它确实可以说明一部分问题。如果以后在实践中遇到了说不痛的情况，我会再进行修改。下面基于上面的结论来分析一下Firefly的操作。 首先Bringover，从服务器获得所有的branch以及里面的文件。基本类似于VSS里面的get latest version。 现在可以对本地工作区进行操作了。Edit将一个文件置于编辑状态，如果愿意，你可以用lock和unlock确定是否独占这个文件；如果改到一半，觉得不好，就Unedit放弃更改使其复原；如果改好了，就Delta，保存修改；如果delta之后，又后悔了，那就rollback；对于非编辑状态的文件，可以delete、undelete、rename、move、addToVersionControl，总之改来改去；如果改来改去还不爽，那就Undo吧，整个本地工作区会回到上次bringover的状态。 现在来putback，把第二步的所有工作传到服务器上去。 upload，不明白。说是用本地工作区来更新服务器上的镜像。那服务器镜像是什么呢？文档也没说，我现在理解可能是将第2步的中间结果暂存一下——万一客户机的硬盘挂了呢！ 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/soobey/archive/2005/08/29/467259.aspx