制作SVN'；外部定义是傻瓜式的吗？

我有一套应用程序都依赖于跨平台库（内部开发），所有内容都存储在subversion中。现在，这个库是每个应用程序的一部分，因此它的副本必须位于每个应用程序的工作目录中

为了能够返回到应用程序的任何版本并拥有正确版本的库，一个选项是在项目中保留库的副本，但是这是一个需要维护的噩梦

更优雅的似乎是使用subversion的功能。然而，似乎有必要使用明确的版本号，以确保100%确保分配了正确的版本（例如，如果指定的主干、标记或分支没有修订号，您似乎无法100%确定是否会得到与一年前完全相同的修订，因为人们总是可以在主干/分支/标记的顶部提交）

现在，该库正在不断开发中，因为它基本上是我们多平台应用程序的核心。因此，维护svn:external道具中的修订将需要不断更新。开发人员对其本地副本进行更改（错误修复、新功能）也是很常见的然后提交。现在我担心，如果我使用修订版设置它，那么将更难跟踪此提交的确切位置（例如，开发人员可能会丢失dep位于分支上的跟踪信息；而且在提交时，它将提交到主干/分支的顶部，可能会跳过其他开发人员的其他提交）

基本上，即使使用外部定义，开发人员仍然需要保持一定的约束和控制来处理这个问题（参见示例）。理想情况下，他们应该足够聪明，但（根据我自己判断）忘记这些小细节是很常见的，可能会在以后引起很多头痛

---

因此，我正在寻找一个真正的傻瓜式解决方案（如果有）为了解决这个问题，使这个库与多个项目保持同步，我可以回到过去，总是得到正确的版本，而不必一直盯着看。

可能有帮助的是限制对标记文件夹的写/提交访问，而不是在svn:externals中使用标记，而不是使用修订号。（即有）

---

因此，用户不能意外地提交到错误的位置，但必须有意识地选择更改所属的分支/主干。

使用svn:externals是可以的（带有修订版），但听起来好像需要使用构建服务器（例如）签入内容时自动生成。这将直接检测开发人员何时进行本地更改并忘记更新外部内容。

您可以使用。

问题在于您的库不是库，至少从严格意义上讲不是

您的“库”可以更好地描述为一个项目，该项目恰好由工作在依赖该核心的不同应用程序上的团队共享

在这种情况下，最大的问题不是您可能选择使用的subversion技术，而是您组织团队的方式，以便在该核心组件上实现有用的协作

可能出现的问题至少有两种。首先，由于不同的应用程序可能需要不同的核心行为，如果它们不能很好地协调，来自一个团队的完全有效的提交将破坏其他团队（持续集成在这里应该会有所帮助）

但第二个问题即使在团队间进行良好沟通的情况下也很难解决，这与发布管理有关

如果依赖于此核心的应用程序在不同的时间点发布，您将很难获得一个稳定的核心，该核心足以发布其中一个应用程序，同时又不会停止其他应用程序的开发

我的建议是，让一个人专门负责核心库。在每个项目中使用核心库的一个分支，让应用程序开发人员在那里提交，同时确保他们与每个人讨论更改，特别是库的监督者

最后，让这个库主管负责协调将不同团队所做的更改合并到库的主干中，从而生成稳定的、经过测试的版本，供应用程序的稳定版本使用。在每次核心版本发布之后，将下一代分支生成到res中这些项目中有三个是不确定的

---

与仅仅定义一个外部库并让每个人都在其中提交相比，这听起来是一项艰巨的工作。但实际上，没有必要隐藏这样一个事实，即您必须付出一些努力来保持核心库的一致性。如果您事先不这样做，它将在以后找到您。

您认为库不是真正的库，但它有点像更容易解释（加上它实际上没有什么区别）。是的，我想这样解释要容易得多。我知道这是一个语义问题，但我认为库或多或少是静态工件，这里不是这样，因为“库”处于开发状态。否则供应商分支会这样做。