我在一家为众多客户进行大量定制开发的公司工作。 一些项目是独特的，但其中许多项目也使用了我们多年来开发的一组通用代码。 这种模式已经运行了很长时间了。 但是我们目前正在从SVN迁移到Mercurial（hg），因此我正在考虑如何最好地建立不同的存储库。
现在，我们有一个内部仓库。 这些项目范围从基本实用程序（例如日志记录）到内部使用的自定义应用程序。 而且，它还有很多旧代码，这些代码不会主动更新，但是会保留下来，以防某些旧的旧客户端代码需要修改。
对于每个客户，我们制作一个单独的存储库，并将他们的所有代码放入专用存储库中。 这种结构的好处是，如果您要处理客户的代码，则只需从客户的回购中获取所有内容，再加上“核心”内部代码，即可获得所需的一切。 缺点之一是客户端代码可能变得过时，甚至与我们核心代码的更改不同步。
但我想听听其他人也做些什么。 拥有许多特定于客户的存储库和一个相当大的内部存储库是否有意义？ 一些客户的代码库很大，而另一些则很小。 每个都有回购协议有意义吗？
另外-我们将所有客户端工件放入每个客户端存储库中。 这不仅包括源代码，还包括规范，合同，已签名的PDF，Excel，Visio，Word和其他此类文档。 这对我来说似乎很浪费，我正在考虑将工件与真实代码分开。 别人如何处理这类事情？
您可以执行以下操作：
这给您带来的好处是，您仍然可以仅提取客户端存储库并获取客户端的内容和核心代码。
另外，子存储库会自动指向核心代码存储库的特定修订版，如果要更新的版本，则必须进行显式更新。 因此，如果核心代码库是在此期间更新，在客户端库中的subrepository 不会自动获得这些变化（这可能会破坏你的客户端代码）。
如果您已经为与您的核心产品代码交互的客户开发了自定义代码，则可能应该在每次核心更新时对其进行审查，以确保它不会“与我们的核心代码更改不同步”。 无论您是收取维护费用还是单独进行检查和维护，这都是有利可图的。 更重要的是，它避免了代码失败。 由客户端存储它使此操作变得更容易。