CVS问题探讨

cjacker

CVS能否有效的管理类似于软件打包的开发任务?
我总觉得CVS不是很有效的方式，简单的FTP加任务分配可能更好一点。

此外，软件包开发涉及到依赖性问题，在协同开发中表现为先后问题，比如:
B软件包由b_people负责
A软件包由a_people负责
但是A软件包依赖B软件包，这就造成了a_people必须等待b_people完成B软件包之后才能进行A软件包，但是在a_people进行的过程中，如果b_people有所update，a_people必须被动的进行update。

这样的问题如何解决？

在Dist协同开发模式上，希望大家提出有效的方式方法。目前，我自己还没有想到什么有效方式。

watercloud

通常是B必须测试自己的代码稳定后才能cvs ci，如果B的更新和以前接口不兼容,更新前必须和A协调好.

cjacker

But,这里是软件包，不是简单的一个程序文件。

怪了，难道大家都不感兴趣？

只有协同开发的协作问题解决，才能有效的开展协同开发。

KDE

会有人的。

myopia

我想 首先打包不要太多人来干
然后 建立打包周期，比如一周 。软件包要带上标记，比如 周期5
由位于依赖树最底层的 maintainer 选择时间宣布打包周期开始，这时从最底层开始更新一次软件包，并且软件标记的周期数加一。不需要改动的软件 just 周期数加一。在一个打包周期内一个软件包只允许在轮到它的时候更新一次，然后就要等待下个周期的到来

caihua

高手的说！

loya

CVS只能管理版本，并不能管理文件间的依赖关系，所以 CVS应该没有什么用处。

要很好的管理打包过程，需要有个好的的计划。如果能够完全识别包间的依赖，可以开发一个工具来管理。

easthero1982

持续关注

EricNeon

已经关注这个帖子好几天了，也苦苦想了好久，没想出办法来。我最近在看POWER4处理器的书，今天突然想到一点：我们是否可以借鉴CPU的“超标量”体系方案来辅助我们的CVS？
所谓“超标量”其实就是并行多个处理器运算周期，也就是说同时处理多条CPU指令流水线。那IBM的star系列处理器举例来说，其使用5级流水线执行powerPC指令每级要求一个处理器周期来完成。
指令读取阶段──在这个阶段，按照分支单元生长的地址，在指令高速缓存中执行读取指令。读取32字节的指令，然后写到位的序列指令缓冲器或8位的分支缓冲器中。
分配阶段──在这一阶段，每一个周期同时解码和分配最多4条32字节的指令。从顺序指令缓冲器或分支缓冲器中按顺序地分配指令，从结构化寄存器、结果缓冲器和结果高速缓存分支中读取操作数。起重，结构化寄存器由体系结构定义。另外，指令高速缓存分支地目标地址也在这一阶段产生。
执行阶段──在这一个阶段,执行运算、翻转和数据高速缓存地址地生成操作。4个执行单元当中由两个是定点运算单元，在一个周期内执行大部分正数运算指令，其中一个单元也执行复杂指令地运算(乘法和除法运算)，使用多个周期来完成相应地操作。第三个执行单元用于浮点运算，也需要多个周期来完成相应地操作。第四个执行单元是加载/保存单元，在单个周期内完成数据高速缓存地址地生成。
正如大多数地处理器一样，star系列处理器能够选择指令并向执行单元发送指令，其顺序可以与出现在指令流中地顺序有所不同。例如，如果指令流中地下一个指令是定点乘法运算，但此周期中，定点单元正在执行先前分配地除法指令，而这个定点单元也能够执行乘法指令，此时处理器硬件有两种选择：一种是直到定点单元完成除法指令，才分配乘法指令；另一种是在该周期内，分指令流种乘法指令后面地指令，让闲置地单元运行。
第一种选择称为顺序执行。第二种选择称为乱序执行。乱序执行被设计到所有新的处理器中，它的执行效率更高，因为它能够让更多的执行单元保持在工作状态，这就意味着整体性能的提高。
不过乱序执行的实现需要付出更昂贵的代价，因为任何乱序执行的指令的运算结果必须等待，直到处理器在指令流中正真遇到这条指令。编译其产生的指令流是假定每条指令按照顺序执行，而改变指令执行顺序，就能够改变程序的结果输出。因此，只有硬件能够保证按照编译器要求的顺序完成指令操作，才允许乱序执行指令。
提交阶段──这一阶段保存执行单元产生的结果。任何乱序执行的指令结果都保存在这一阶段，只到指令流中位置靠前的指令全部执行完毕。使用这个方法，指令虽然是乱序执行，但是它们总能够按顺序提交结果。执行分支指令、程序异常、缺页中断都能导致提交阶段(和前面几个阶段)的失败。
回写阶段──在解决了所有的分支和异常阶段以后，回写阶段把指令结果写回到结构化寄存器中。

EricNeon

条件分支指令是流水线处理器的最大敌人。因为使用条件分支指令，只有当处理器硬件对条件进行判断后，才能知道分支(即确定下一个指令的位置)输出。使用流水线记述的处理器每一周期开始执行单个新指令(超标量体系结构的处理器在每个周期就开始执行多个指令)，因此，这个问题就变成，紧随条件指令之后，应该执行哪一条指令？处理器应该猜测不会发生指令分支跳转，因而选择执行指令流中跟着分支指令后面的指令；抑或处理器应该猜测分支指令会被执行，因而开始执行分支指令中跳转地址所指向的指令呢？
无论上述哪种情况发生，处理器都可能有时判断正确，有时判断错误。当处理器判断正确时，流水线满负荷工作，不再有时间损失。然而，当处理器判断出错时，流水线必须清空指令(通常叫做刷新流水线)，重新从正确的分支路径取出指令，然后使用新指令再重新起动流水线。刷新和重启将花费一段较长的时间，而且因为分支指令再大多数的程序中非常常见，这些操作将大大降低处理器的整体性能。我们把这种因判断出错而产生的性能损失称为分支预测错误损失。它的时间定义从分配一个分支指令开始，到分配分支指令的正确的目标为止。

为了帮助处理器更见正确地判断是否执行了分支指令，大部分RISC处理器都使用某种形式地硬件分支预测。当今应用最广泛地专用分支预测技术称为分支目标缓冲器。分支目标缓冲器是在处理器芯片上实现地一张专用表格，主要用于跟踪在指令流中刚刚遇到地分支指令。另外，表格页跟踪记录了最新遇到地分支指令地跳转目标地址。

在指令读取阶段，每一条被读取地指令地地址将会与表格中地地址相比较。如果地址匹配，尽管实际地指令解码要等到下一个阶段才开始，但是在指令读取阶段还是知道处理器读取了一个分支指令。指令读取阶段接着使用存储在表格中的分支目标的跳转地址，开始下一个周期从目标跳转地址指示的位置读取指令。换句话说，指令读取阶段预测分支指令的执行结果将会与上一次的执行结果完全相同。

如果条件判断完成后，并且发现预测成立，那么将不会发生任何事情。因为预测正确，在流水线中时间周期没有任何时间损失，所以每一条指令都可以在指令读取阶段得到处理。如果条件判断完成后，发现预测不正确，处理器将为分支预测的错误付出代价，流水线必须刷新重启。在这种情况下，表格中的分支目标跳转地址必须改变，以反映新的分支目标跳转地址。当然，当处理器第一次遇到分支指令时，在分支目标缓冲器中必须创建新的入口点。

大部分RISC处理器中的分支目标缓冲器在执行科学计算的工作负载时，判断的正确率在85%-95%之间。之所以有这样高的正确率，原因是技术计算通常涉及许多循环处理，处理器需要多次重新执行指令循环。在指令流中，相同的分支指令将会重复执行多次，所以对于这类处理工作，分支预测能够很好的完成。

而对于商业工作负载来说，则循环很少，分支预测正确率只有50%。因此star系列处理器并不采用分支预测，而是使用早先在Muskie处理器中使用的一种技术，这种技术可以把处理器中的分支预测失误的损失降到最小，或最多损失一个指令周期。之所以这样，是因为它不是试图预测需要哪个分支目标，而是对两个分支目标都预取指令，为执行两个分支的支路都做好准备，这就是精妙之处。

EricNeon

从上面两个帖子大家应该对流水线的工作原理有了一定的了解了。我们就拿来主义，把流水线超标量设计应用到我们的开发管理中来。

首先，我们提供一份完整的LINUX软件包的依赖关系树图；
然后提供一份magic所依赖的软件包依赖关系图；
提供如kernel、Xfree、libs、kde、gnome、office等主要组件未来发展方向的前瞻性分析图，以便给所有关注magic开发的朋友一个清晰的发展路线；

以上提供这些基本的依赖图的目的正是相当于建立了一种分支预测机制，也为很多想学习linux的朋友提供了一个给自己定位的参考。同时，这样做的好处是可以保证所有参与magic的rebuild工程的朋友建立起标准的编译环境。

然后，由一两个指定的成员搜集并提供最新“核心组件”的源代码，这部分核心组件应该是依赖层的最底层。
然后从第二层开始将任务分成几个完全独立的局部任务，并同时开始独立运作。在这个过程中，如Kernel、中文化设置等可作为全局任务与其他各部分同时运作。

建立一个“触发事件条件表”，也就是在前瞻分析图中选择未来可能的触发事件，并将这些事件定为条件写入条件表中。一旦国际开发团队的某些软件组件有新的发布和更新，核心组成员应及时更新“核心组件”代码，并编辑“触发事件条件表”，所有既行任务照旧运作。直到一个流水线完成或者失败，此时可以按照触发事件条件表查询“条件”，如果条件满足，则意味着应该升级源码包。
“触发事件条件表”也可作为发行版版本定制的一个简单的依据，以便所有关注magic的朋友清楚的了解到magic每一个测试版和正式版的发布日期及当前任务。

KDE

天书

easthero1982

[quote:1189521fa9="KDE"]
天书
[/quote]
同感

xLoneStar

参考一下 Rawhide/Fedora 和 Mandrake Cooker 的运作，会有帮助

CVS 在管理 rpm 的 spec 以及补丁文件时是有效的，但，当然，它管不了依赖性

watercloud

EricNeon //hand
<<罗彻斯特城堡>>
看了4个月看完。

突然想起来,cjacker好象对IBM的咚咚俱熟。