Svn 代码库最佳实践

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

目前，我们的内部工作有一个回购协议。这些项目范围从日志等基本实用程序到内部使用的自定义应用程序。而且它还有大量的旧代码，这些代码没有被积极更新，而是保留下来，以防需要修改一些旧的遗留客户端代码

对于每个客户，我们进行单独的回购，并将其所有代码放入专用回购中。 这种结构的好处在于，如果你想处理客户的代码，你只需要从他们的回购中获得一切，再加上“核心”内部代码，你就拥有了你所需要的一切。一个缺点是客户端代码可能会过时，甚至与核心代码的更改不同步

但我也想听听其他人也在做什么。拥有许多特定于客户端的存储库和一个相当大的内部存储库有意义吗？一些客户机的代码库很大，而另一些客户机的代码库很小。为每个人都进行回购有意义吗

---

此外，我们将所有客户机工件放入每个客户机存储库中。这不仅包括源代码，还包括规范、合同、签署的PDF、Excel、Visio、Word和其他此类文档。这对我来说似乎是浪费，我正在考虑从真实代码中分离出工件。其他人是如何处理这些事情的？

如果您已经为客户开发了与您的核心产品代码相互作用的自定义代码，您可能应该在每次核心更新时对其进行检查，以确保它不会“与我们的核心代码的更改不同步”。无论您是收取维护费用，还是单独进行审查和维护，这都是有利可图的。更重要的是，它避免了失败的代码。通过客户端存储它可以简化此操作。

您可以执行以下操作：

• 将核心代码放在一个中央存储库中
• 将客户机代码放入特定于客户机的存储库中
• 不要将核心代码的副本直接放在客户机存储库中，而是将核心代码存储库作为

这样做的好处是，您仍然可以提取客户机存储库并获取客户机的内容和核心代码。

---

另外，子存储库会自动指向核心代码存储库的某个版本，如果您想要更新版本，则必须进行显式更新。因此，如果同时更新核心代码存储库，则客户端存储库中的子存储库不会自动获得这些更改（这可能会破坏客户端代码）。

！子存储库似乎是一个不错的选择。如果我的核心回购有10个不同的项目，我是否可以只将客户代码使用的项目作为子存储库？不要将多个项目放入一个回购中。我的意思是，你在他们之间建立了不存在的依赖关系。例如，要回答您的问题，如果它们在同一个存储库中，您必须包含所有这些内容。最好在10个回购协议中包含10个不同的核心项目。它既便宜又简单，没有真正的理由不这样做。如果可能的话，从人工制品中收集依赖项，并将它们组合到构建中（使用Maven或Ivy），而不是子存储库。子存储库有一大堆概念问题，很少是最好的解决方案。