代码库最佳实践

时间:2011-12-27 16:45:31

标签: svn version-control mercurial

我在一家为各种客户进行大量定制开发的公司工作。有些项目是独一无二的,但其中许多项目也使用了我们多年来开发的一组通用代码。这种模式长期以来运作良好。但是我们目前正在从SVN迁移到Mercurial(hg),所以我在考虑如何最好地设置不同的存储库。

现在我们的内部工作有一个回购。这些项目包括从日志记录等基本实用程序到内部使用的自定义应用程序。它还有大量未经过主动更新的旧代码,但如果需要修改一些旧的遗留客户端代码,请保留这些代码。

对于每个客户,我们制作单独的仓库并将所有代码放入专用仓库。 这个结构的好处在于,如果你想要处理客户端的代码,你只需从他们的repo中获取所有内容,再加上“核心”内部代码,你就拥有了所需的一切。一个缺点是客户端代码可能变得陈旧,甚至与核心代码的更改不同步。

但我想听听别人做的事情。拥有许多特定于客户端的存储库和一个相当大的内部存储库是否有意义?一些客户的代码库是巨大的,而其他客户的代码库非常小。为每个回购都设一个回购股票是否有意义?

此外 - 我们将所有客户端工件放入每个客户端存储库。这不仅包括源代码,还包括规范,合同,签名PDF,Excel,Visio,Word和其他此类文档。这对我来说似乎很浪费,我正在考虑将文物与真正的代码分开。其他人如何处理这类事情?

2 个答案:

答案 0 :(得分:1)

您可以执行以下操作:

  • 将核心代码放在一个中央存储库中
  • 将客户端代码放在客户端特定的存储库中
  • 执行将核心代码的副本直接放在客户端存储库中,而是将核心代码存储库包含为subrepository

这为您提供的好处是,您仍然可以拉客户端存储库并获取客户端的内容核心代码。
此外,子存储库会自动指向核心代码存储库的某个版本,如果您需要更新版本,则必须进行显式更新。因此,如果在此期间更新核心代码存储库,则客户端存储库中的子存储库会自动获取这些更改(这可能会破坏您的客户端代码)。

答案 1 :(得分:0)

如果您为客户开发了与您的核心产品代码相互作用的自定义代码,您应该对每个核心更新进行检查,以确保它不会“与我们的核心代码的更改不同步”。无论您是要进行维护还是单独进行检查和维护,这都是有利可图的。更重要的是,它避免了代码失败。通过客户端存储它可以使这更容易。