这里讨论的tag 是非分支的普通标签.
tag 并非一定是CVS的一个快照, 因为tag可以打在仓库文件的任意一个子集上, 也就是说, 通过cvs log 查看各个文件的版本时, 你会发现, 有些文件有tag, 而另一个则没有.
cvs tag tag_name file1 file2 file2 dir1
被tag所标注的文件其特定版本就被精确地锁定到一个revision 号上了, 问题是: 过一段时间之后, 如果发生了bug 或新的版本与老版本行为发生了奇怪的不同, 你往往希望知道是你打一个tag时, 整个仓库中的每个文件都是个什么状态, 不幸的是, 如果一开始你的tag只打在了你check in的那些文件身上, 没有简单可靠的办法知道那些时间点其它的文件都是什么版本.
打tag, 说的简单, CVS系统中到底发生了什么, tag名字与特定文件的一个特定修订号关联起来, 一起写在
该文件处于CVS仓库中的,v 文件中, 而对于这个tag没有"打"到的那些文件, 什么都没有发生. 所以如果你希望知道你check in的5个文件时整个系统的一个快照, 你不能只给这5个文件打标签, 显然, 只给指定的少数文件打标签, 速度很快. 要得到完整快照, 就得给整个module打标签, 这个当然很慢, 因为系统中每个文件都得打开, 插入标签名并与某个版本号关联起来, 写入文件然后存盘.
对于CVS来说, 据我所知没有捷径.
当然, 如果你只是给少数几个文件打了标签, 又偏偏想知道打标签的时间点上整个系统的快照, 如果这对你真的很重要, 这里有一个我没有验证的办法:
首先找到至少一个被打了标签的文件, 光这一步也不是那么简单, 如果你碰巧忘了标签的具体名字和任何一个文件的名字.
假设你还是找到了, 可以用cvs log filename来查看该标签打在了哪个版本上, 而该版本被checkin 的时间是什么.
然后根据这个时间, 最好精确到秒, 用 cvs checkout -D "精确的时间" 来得到那个近似的快照, 因为cvs的commit不是原子性的, 无法保证那个时间没有其它人在提交跟你不同目录的东西.
http://wiki.tryphon.org/development_branch_with_cvs
这个网页中建议的方法让我开始认真考虑怎么用CVS来辅助变更/BUG管理, 它建议对每一个改动都建立两个标签, 比如有一个问题, 编号为1.
cvs tag issue-1-before .
这一步在check in你的修改之前. 其中"."代表对整个module打标签.
而check in之后, 再执行:
cvs tag issue-1-after .
每一个问题都有一个成对的before和after, 对于后面的追踪很容易.
试用了几次这个方法之后, 我很快被在整个module上打标签的巨大时间代价弄的不耐烦了, 而且, 通过tortoise cvs这样的工具查看版本revision的图示时, 出现了过多的tag, 把本来就已经很多的版本号弄得更加拥挤了, 在22寸的屏幕上还是很难一次看到文件的所有更改历史.
这个办法的引人之处就在于它是精确的, 每一个改动都是精确可追踪因而也是可回溯的, 仔细思考之后, 我发现了一个更好的办法来做这件事:
issue-1-before 还是要打在整个标签上
但 issue-1-after 可以只打在你自己check in的少数一些文件上, 因为打这两个标签的时间都是相隔很近, 此时绝大多数文件的版本正是 issue-1-before标签所标定的版本, 而issue-1-after 的优势在于它只打了那些与before 不同的部分.
具体想得到 issue-2-after 那个时间点的快照时, 需要先按 issue-1-before得整个module, 然后用issue-1-after 来替换那些在此次提交中真正改变了的文件, 没有改变的文件则保持是before 标签所标定的版本. 如此得到的仍然是一个精确的快照.
阅读(938) | 评论(0) | 转发(0) |
