CollabNet的一个客户最近发布了这� �一个问题：
我们为CollabNet主持的多个Subversion版本库设置了镜像，我有一个关于同步频率的问题，保持怎� �的同步频率？在一些小的修改就同步还是在一些大的修改完成时再同步？
结果是我确实曾经考虑这个问题，Subversion的动态镜像管理非常有趣，所以这给了我机会来润色我的一些思考，� 为这个客户的Subversion开发场景并不独特，所以您也能够从我的回复里得到益处。
我的回复是：
这是一个有趣的问题，我最近曾经认真思考过。如果� 希望“每X分钟同步一次”之类的回答，那� 不会满意的，答案需要� 平衡镜像的作用和维护他们所经受的复杂度之间的关系。
让我们从最原始的同步方法开始，� 每过� 分钟同步一次。依赖于� 如何使用镜像，精确的分钟可能会变化。如果是简单的夜间备份，60 x 24 = 1440分钟足够好，但是如果镜像会作为开发者使用的快速变化的代� �基时，这就不够了。� 也许需要每20，5或1分钟同步一次。当然� 不希望� 为太频繁的 同步影响服务器的性能（发起拒绝服务攻击（DoS）并不明智），但是尝试已经同步过的镜像的代价并不是那么大。
现在，如果版本变更数据是同步任务唯一维护的数据，选择svnsync sync会和上面一� �简单。不幸的是，也有一些未版本化的属性也需要关注，� 为当� 同步Subversion版本库的时候，Subversion不会记录 � 所做的事情，完整的Subversion版本库同步变得复杂起来。假如� 在master版本库有100个修订版本，� 保持了镜像的同步。之后，一个开发 者修改了修订版本50的日志信息，svnsync不会识别出发生的百年更，以后的svnsync sync只会同步修订版本的增� （r101或后面的），但是r50的日志在镜像中已经不同了。svnsync copy-revprops子命令可以弥补这个问题，但是� 需要告诉这个子命令一些关于对于那个版本操作的信息。
所以修订版本同步增� 了复杂性。大多数时候，开发者可以快速的识别日志信息的错误，并在提交后迅速修正这个问题，只要他们能在同步工作同步这个修订 版本之前执行修正，对镜像来说毫� 问题。所以这让我们不要频繁的执行同步（只要修正发生在之前），但是多长是足够的呢？但是如果修改的日志信息是� 个月以 前的修订时怎么办？这个问题需要� �据镜像的目的来回答，在� 的情况下，修订版本属性是否不同步是否很重要？也许不是，也许很久以前的修订版本属性不同步没 有关系。可能在� 的情况下，是每10分钟的一个修订版本同步和一个每夜的全修订版本同步。
（我承诺过的，我会提供更多的答案。）
依我看来，最好的方法是多方面的，实时的事件驱动的触发器和预定的以防万一的同步工作。
第一部分的情况是，除非在master版本库和镜像之间发生通讯错误，都会尽可能保持同步。理想情况下，� 的主版本库可以推出修改到镜像，或至少能 够推出变更的通知。例如，� 的主版本库可能有post-commit和post-revprop-change钩子来运行svnsync 来直接同步镜像，如果由于防火墙或安全的原� 这� �做不到，，那么或许可以让post-commit 和post-revprop-change钩子至少发送变更的通知邮件，镜像主机有一些自动化的方法可以发现这些邮件并触发相关的sync任务，一个提交 邮件触发svnsync sync;，一个属性变更邮件触发修订版本的svnsync copy-revprops。
另一方面覆盖了万一的情况。如果镜像主机为能够获得提示邮件？或如果sync工作遭遇网络问题？为此，� 或许需要一些有规律的计划任务，会尝试svnsync sync（可能没有同步的东西，� 为事件驱动的属性同步工作正常），然后svnsync copy-revprops跨越多个修订版本（通常会重写相同的属性，� 为同� �的原� ），当然需要避免的是防止svnsync任务对同一个版本库的资源争用。
也许不是完全的有指导意义，我希望� 能够有足够的信息来决定如何实现最适合� 的工作。
About the Author
C. Michael (Mike) Pilato has been on the Subversion project as a committer since 2000. Mike is one of the co-authors of “Version Control with Subversion” and he is on the board of the non-profit Subversion Corporation.
TAG: 管理 频度 sync 镜像