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