| 前页 | 后页 |
版本控制Locking Overview
Enterprise Architect通过将包数据从项目数据库导出到 XMI包文件来实现模型的版本控制，这些文件位于源代码控制应用程序的版本控制下。 XMI 文件格式不能像普通文本文件那样被合并，这就是为什么Enterprise Architect必须强制对版本控制包进行序列化编辑，正如这里所讨论的。
锁定-修改-解锁解决方案
许多版本控制系统使用lock-modify-unlock模型来解决不同作者在共享源中覆盖彼此作品的问题。在这个模型中，版本控制库一次只允许一个人更改一个文件，并且使用锁来管理访问。
Harry 必须先锁定文件，然后才能开始对其进行更改。如果 Harry 锁定了一个文件，Sally 也不能锁定它，因此不能对该文件进行任何更改。她所能做的就是阅读文件，然后等待哈利完成他的更改并释放锁。哈利解锁文件后，莎莉可以轮流锁定和编辑文件。
复制-修改-合并解决方案
Subversion、CVS 和许多其他版本控制系统使用复制-修改-合并模型作为锁定的替代方案。在此模型中，每个用户的客户都联系项目存储库并创建个人工作副本 - 存储库文件和目录的本地反映。然后用户同时独立工作，修改他们的私人副本。在适当的时候，私人副本会合并成一个新的最终版本。版本控制系统通常会协助合并，但最终由一个人负责使其正确发生。
需要锁定时
虽然 lock-modify-unlock模型通常被认为是协作的障碍，但有时仍需要锁定。
复制-修改-合并模型是基于文件是上下文可合并的假设：即存储库中的文件是基于行的文本文件（例如程序源代码）。但是，对于具有二进制格式的文件，例如艺术品或声音，通常不可能合并冲突的更改。在这些情况下，用户确实需要严格轮流更改文件。如果没有序列化访问，一些用户最终会在最终被覆盖的更改上浪费时间。