| 前页 | 后页 |
版本控制锁定概述
Enterprise Architect通过将项目数据库中的包数据导出到 XMI包文件来实现模型的版本控制，这些文件位于源代码控制应用程序中的版本控制之下。XMI 文件格式无法像普通文本文件那样进行合并，因此Enterprise Architect必须强制对版本控制的包进行序列化编辑，正如本文所述。
锁定-修改-解锁解决方案
许多版本控制系统使用锁定-修改-解锁模型来解决共享源中不同作者相互覆盖彼此工作的问题。在此模型中，版本控制存储库每次只允许一个人更改文件，并使用锁来管理访问权限。
Harry 必须先锁定文件才能开始修改。如果 Harry 锁定了文件，Sally 就无法锁定它，因此也无法对该文件进行任何修改。她所能做的就是读取文件，并等待 Harry 完成修改后解除锁定。Harry 解锁文件后，Sally 才能锁定并编辑该文件。
复制-修改-合并解决方案
Subversion、CVS 和其他一些版本控制系统使用复制-修改-合并模型作为锁定的替代方案。在此模型中，每个用户的客户端都会访问项目存储库并创建一个个人工作副本——存储库文件和目录的本地镜像。然后，用户可以同时独立地修改各自的私有副本。在适当的时候，这些私有副本会被合并成一个新的最终版本。版本控制系统通常会协助合并，但最终需要用户负责确保合并操作的正确完成。
何时需要锁定
虽然锁定-修改-解锁模型通常被认为是协作的障碍，但有时锁定仍然是必要的。
复制-修改-合并模型基于文件上下文可合并的假设：即存储库中的文件是基于行的文本文件（例如程序源）。然而，对于二进制格式的文件（例如插图或声音），通常无法合并冲突的更改。在这种情况下，用户确实有必要严格轮流更改文件。如果没有序列化访问，一些用户最终会浪费时间在最终被覆盖的更改上。