代码之家 › 专栏 › 技术社区 › G__

要嵌入到自定义编辑器应用程序中的源代码管理范式和解决方案是什么?

version-control application-design

2

G__ · 技术社区 · 14 年前

我正在构建一个管理许多自定义对象的应用程序,这些对象可以由多个用户(使用应用程序的不同实例)同时编辑。这些对象有一个底层的序列化表示,我的计划是(通过我的应用程序UI)在外部源代码管理系统中持久化它们。当然,这意味着我的应用程序可以检查对象的当前版本是否有更新、每个对象的合并接口等。

我的问题是要支持什么样的源代码管理范式和特定的解决方案,以及为什么。我(也许是天真的)看待源代码管理世界的方式是三个一般的范例:

单个存储库,锁定访问(MS SourceSafe)
单一存储库,并发访问(cvs/svn)
分布式(Mercurial,Git)

我已经有很多年没有听说有人使用1了,所以我打算完全忽略这个案例(除非我有一个令人信服的论点)。然而,我对是否支持2或3以及哪些具体实现感到茫然。我担心的是,使用模式有着细微的差异,以至于我无法在单个UI中充分地捕获基本操作。

我要传达的最后一点信息是,这个应用程序将部署在一个商业环境中,在这个环境中,源代码控制系统可能已经在使用。我宁愿不支持多个解决方案,除非它真的是一个交易破坏者,所以在公司环境中广泛采用是一个优势。

更新 : 我特别寻找一些推理:

哪种模式有意义,因为它是商业上接受的?(我想这个答案是@andrew colson,但其他人的经验可能不同)
一个普通的商业开发商店会喜欢使用现有的源代码控制系统,而不是为我的应用程序维护第二个源代码控制系统,这是一个合理的假设吗(假设我的应用程序满足一个独立于正常开发过程的非平凡需求)?
根据我的需要,我是否正确地假设2和3不能被合理地捕获到一组操作中,而不扭曲其中一个范例?
对于您认为我应该使用的范例,您认为支持哪些特定的实现是关键的?

2 回复 | 直到 14 年前

1

2

Evan Plaice 14 年前

α2和/或γ3

#1 单一存储库,锁定访问-现在很少使用,所以它们不值得一提。

#2 单一存储库、并发访问(concurrent access)被称为VCS或CVCS(集中式版本控制系统),目前仍被广泛使用。

#3 分布式——是下一件大事,因为它们消除了其他系统对开发人员施加的许多人为障碍。

首先,回答您的问题/顾虑:

1. 商业接受取决于组织和它的开发人员。如果管理者是负责所使用软件的人,并且他们倾向于在几乎没有实际证据的情况下严格执行保守的决定,那么他们可能会默认微软提供的一切。在这种情况下,祝你好运。我所听到的关于MS版本控制(特别是SourceSafe)的一切都是坏事,我不确定MS是否有DVCS选项。

Otoh,如果开发团队负责选择他们的工具(或者管理者思想开放),那么可能Git或Mercurial就是解决之道。Git会很难适应,因为它过于复杂。Mercurial是一个非常容易从CVC过渡的版本,一定要下载TortoiseHgGUI客户端来了解工作流。两者都是完全稳定的,可以生产了。mercurial和subversion用于sourceforge.net和google代码,这两个代码都可以承载数千个项目。他们可能有任何错误,或者他们知道他们已经解决了。

2. 当我说“在这个时代,滚动你自己的版本控制系统是一种荒谬的浪费时间和精力”的时候,我很肯定我代表了整个开发人员。

当然,您可能会制作一个特别用途的版本控制系统,它很小,适合您的应用程序;但是,在您决定之前,请考虑在这项工作中所涉及的所有时间和精力。更不用说,您需要将版本控制系统的代码置于版本控制之下。努夫说…

3. 不,你不是,你可以同时使用。许多人使用cvc(通常是颠覆性的)在整个组织范围内集中版本控制,同时使用dvc在本地以较小的组或单独开发(甚至微软工程师在其开发小组中秘密使用git)。由于dvc在文件系统中只由一个隐藏的文件夹和一个忽略文件来表示,所以很容易将所有的信息添加到cvcs忽略文件中,这样就不会在中央存储库中跟踪信息。简单点,如果必要的话,你可以利用两者的优势。

我认为甚至有方法可以在提交时将dvc的提交历史转移到cvc。尽管如此,我也不知道怎么做,因为我从来没有理由这么做。

4. #2和/或3肯定。

如果已经有了一个CVC,并且您需要使用它,我会说两者都有。

Subversion可以做任何事情,但问题是,CVC的所有版本历史都保存在服务器上。也就是说,如果你没有直接的网络访问权,你就不能提交或更新。这对一些开发人员来说是很好的,但是大多数开发人员都在移动中,当他们需要工作时并不总能找到网络连接。关于这一点的坏部分是提交被拖出,它们最终会处理与主干开发分支进一步不同步的源代码。Subversion(或通常的cvc)在处理分支方面也很糟糕,这意味着,如果有两个开发人员在主线的两个不同分支上测试想法,并且他们决定将它们重新合并在一起,那么情况会变得很糟糕。dvc在分支上更好。

如果没有CVC,则仅使用DCVCS。

DCV能够做任何事情,因为您可以让存储库的远程克隆充当存放点。工作流的区别在于,当您提交到一个CVC时,如果没有问题,它会直接进入远程存储库。在DCV中,当您提交时,如果没有更改,它将提交到本地存储库。然后,在您准备好发布一组更改之后,您将(或在mercurial中同步)提交到远程服务器。

由于DCV中的存储库都是相同的,所以无论位置如何,您都可以从任何其他存储库推/拉。开始的时候把头包起来有点难,但它有一些明显的优点。首先,无论您到哪里,您都会随身携带项目的历史记录,因此,如果中央服务器出现故障,所有开发人员都会随身携带项目的备份副本,因此这不是什么大问题。第二,允许开发人员在任何时候无限制地提交是非常有益的。开发人员提交的越多,版本历史就越详细,如果需要回滚代码,发现问题的速度就越快。

实现你所描述的。在您希望的任何位置创建启动程序存储库。它所需要的只是网络接入。

将初始文件复制到项目文件夹并提交它们。

让所有处理这些文件的人克隆他们自己的存储库副本。

如果需要以编程方式进行更新,可以检查是否需要从中央存储库中提取更改,或者在必要时提交并推出新的更改,所有这些都使用命令行。

只要您可以将串行数据写入受源代码管理的文件夹中的文本文件,这就不是问题。在提交/推送时,您必须手动解决冲突,但任何版本控制系统都需要这样做。

如果要确保远程存储库和本地存储库之间很少或没有冲突,请在提交之前始终拉取本地副本。这样,如果发生冲突,就可以在本地处理。

我只有这些。

2

Andrew Coleson 14 年前

如果你想获得广泛的商业支持,你现在看到的更多是2而不是3(甚至可能是1)。

编辑: 当然,这取决于您所说的“商业”的含义,但是大型商业组织在开发人员工具中往往落后于曲线。我主要看到了每个项目/组的供应链管理,但我敢肯定技术性商业组织可能只使用由其IT组提供的单一供应链解决方案。