我有一组应用程序都依赖于跨平台库（内部开发），所有内容都存储在subversion中。现在，这个库是每个应用程序的一部分，因此它的副本必须位于每个应用程序的工作目录中。
为了能够回到任何版本的应用程序并拥有正确的lib版本，一个选项是在项目中保留lib的副本，但这是一个维护的噩梦。
更优雅似乎是使用subversion的externals definitions功能。但是，似乎有必要使用显式修订号来100％确保分配了正确的修订版本（例如，如果指定了主干或标签或分支没有修订号，则看起来您不能100％确定你是否会像一年前那样获得完全相同的版本，因为人们总是可以在trunk / branch / tag之上进行修改。
现在，这个库正在不断发展，因为它基本上是我们多平台应用程序的核心。因此，维护svn：external prop中的修订需要不断更新。 devs通常会更改其本地副本（错误修正，新功能）然后提交它。我现在害怕，如果我使用修订版进行设置，将很难追踪到这个提交的确切位置（例如，开发人员可能会忘记dep在分支上;也就是在提交时，它将被提交到顶部主干/分支，可能跳过其他开发者的其他提交。）
基本上，即使使用外部定义，使用它的开发人员仍然需要保持一定量的约束并控制处理这个（参见例如example on SO）。理想情况下，他们应该足够聪明，但是（自己判断）忘记这些小细节是很常见的，可能会在以后引起很多麻烦。
所以，我正在寻找的是一个非常简单的解决方案（如果有的话），这个问题是让我的lib与几个项目保持同步，这样我就可以回到过去，并始终得到正确的版本在一起而不必经常出现在手表上。
答案 0 :(得分：3)
您的问题的问题在于您的库不是库，至少不是严格意义上的表达式。
您的“库”更好地描述为一个项目，该项目恰好由处理依赖该核心的不同应用程序的团队共享。
在这种情况下，最大的问题不是您可能选择使用的颠覆技术，而是您组织团队的方式，以便在该核心组件上实现有用的协作。
可能出现的问题至少有两个。首先，由于不同的应用程序可能需要与您的核心不同的行为，如果它们不能很好地协调，一个团队的完全有效的提交将打破其他的（持续集成应该在这里帮助）。
但即使有良好的团队间沟通，第二个问题也难以解决，而且与发布管理有关。
如果依赖于这个核心的应用程序在不同的时间点发布，那么你将很难获得一个稳定的核心，这个核心足以发布一个应用程序而不会停止其余的开发。
我的建议是，有人致力于照顾核心库。在每个项目中使用它的一个分支，让应用程序开发人员在那里提交，同时确保他们与每个人讨论更改，特别是lib的监督。
最后，让这个库管理员负责协调不同团队所做的更改合并到库的主干中，从而生成稳定的，经过测试的版本，这些版本将由应用程序的稳定版本使用。每次发布核心后，都会将下一代分支产生到其他项目中。
与仅仅定义外部并让每个人都在那里投入相比，这听起来像很多工作。但实际上，没有必要隐瞒这样一个事实，即你必须付出一些努力来保持核心库的连贯性。如果你不提前做，它会在以后追捕你。
答案 1 :(得分：1)
可能有用的是限制对tags文件夹的写入/提交访问权限，而不是使用svn：externals中的标记而不是修订版本号。 （即svnperms）
因此，用户不会意外地提交到错误的地方，但必须有意识地选择更改所属的分支/主干。
答案 2 :(得分：1)
使用svn：externals很好（ with revisions ），但听起来好像你需要使用一个构建服务器（例如Hudson），它会在签入内容时自动构建这将直接检测开发人员何时进行本地更改并忘记更新外部。
答案 3 :(得分：0)
您可以使用Vendor Branches。