从SVN移动到HG:分支和备份

不过,我担心合并 更改和跟踪历史可能 在分支之间变得困难 这个模型。

好吧,您已经决定要将分支保存在单独的克隆中,这不是免费的。但是,设置一个存储库级别的配置文件,将所有克隆命名为别名,以简化pusing/pulling并不是什么大问题。

如果我们团队中的程序员 分支的克隆,它们如何备份 本地克隆?我们已经习惯了 SVN在 功能分支“临时提交:db 功能尚未工作”。我看不见 一种在汞柱中很容易做到这一点的方法。

这是使用DVC的首要原因,因为它完全支持这个用例。提交是本地的,直到您推动它们。这意味着每个开发人员都可以创建他认为合适的尽可能多的“interims”提交。但这并不是原始意义上的“备份”,它更像是单个开发人员的“保存点”。到目前为止,您一直在用那些Interims提交来混乱您的历史,这些提交被共享给您团队中的所有开发人员。使用Mercurial队列,您可以在推送之前轻松地将所有Interims提交“折叠”在一起,从而在中央存储库中形成一个干净的历史记录。

如果真正的备份(从这样的意义上说:如果这个开发人员的机器着火了会发生什么)是一个问题,答案很简单:只需给每个开发人员一个私有的服务器存储库,在那里他可以定期推送。

我无法与您的SVN分支迁移问题联系。您的解决方案听起来不错,但并发性非常困难,我还没有充分考虑到您的情况。

但是假设您确实为每个“SVN分支”在服务器上创建了一个单独的存储库,那么我相信您可以很容易地解决第二个问题。首先,遵循 Peter Loron's advice 通过复制文件来完成工作。然后,每当开发人员准备好提交到“我们团队的基于服务器的存储库”*时,他们就可以提交,就像“hg分支”:在同一个存储库中一样。您将得到与“临时提交:DB功能尚未工作”相同的提交,但它们不会在主干上破坏每个人的构建。

所有这些工作的关键,以及hg/git如此酷的原因,是当这个特性实际完成时,您将这个“hg分支”合并回同一个存储库中的主干中,并且自动合并将比使用SVN更好。

如果需要大量并发开发,则需要使用分布式版本控制系统、ClearCase或Performance。ClearCase和Performance不进行分布式版本控制,但它们处理合并的能力可能比其他大多数工具都要好。

ClearCase的合并是为并发开发而进行的,并且工作得非常好。事实上,ClearCase中的大多数开发人员在自己的分支上开发,然后将他们的更改合并到 集成流 当他们的工作完成时。ClearCase之上的UCM层简单地自动化了这种行为。

Perfonce的合并更符合他们所说的 发散分支 但它似乎可以处理并发开发。

Subversion是一个不错的版本控制系统。我经常使用它,而且你不能打败价格,但让我们面对它,合并在颠覆仍然非常,非常粗糙的边缘。使用属性跟踪合并非常简单。当您查看日志时,您会看到许多更改,这仅仅是由于Subversion更改了svn:merge属性所致,即使文件基本上没有受到影响。另外,您必须知道何时使用--reintegrate标志。

当然,分布式版本控制系统处理并发开发的时候很有条理。从一开始就是这样设计的。

我唯一的问题是,为什么您要进行这么多并发开发?多年来,我发现强迫开发人员在同一组变更上协同工作是最有效的。当被迫处理同一组代码时,开发人员对他们的开发更加小心。它们取较小的 咬 ,对变化更加小心,并更多地相互沟通。

当我在ClearCase中与开发人员一起工作时,每个开发人员都有自己的分支,我使用它来确保开发人员定期合并他们的更改。在没有人的情况下编程要容易得多,但是您正在更改代码。开发人员只需在自己的分支上完成所有的工作,而不必每次都得到其他开发人员所做的更改。您有20个开发人员都在这样做,并且在主分支上看不到任何变化。然后在交付之前,开发人员将对所有更改进行大规模合并。接着就是欢闹。

接下来的一周,我们将尝试清理所有内容,让开发人员的所有更改协同工作。QA很沮丧,因为他们几乎没有时间进行测试。在未经测试的情况下,释放出来并不少见。毕竟,我们还有最后期限要满足。

有充分的理由进行并发开发,但我发现很多时候是开发人员请求它,因为它使他们的工作更容易。他们不必协调他们的更改,因为现在 你的 工作。毕竟,这就是他们付给你大笔钱的原因。

嗯,不是很高的钱,但你的薪水比很多人都高。也许不是开发人员,但你比你公司里的其他人,比如看门人赚得更多——除非他属于工会。嗯,你有股票期权。

建议:同时检查Git。

对于任何分布式版本控制系统(如hg或git),您的repo本地副本都包含工作文件和本地存储库。这可能是你想要的所有备份。如果需要更多,只需将文件(包括.hg或.git目录中的repo文件)复制到备份位置即可。