我的公司无法找到管理构建，发布和分支的最佳方法......我们的基本设置是我们有4个应用程序，我们维护2个WPF应用程序和2个ASP.NET应用程序，所有这些应用程序中的4个共享公共库，所以目前他们都在一个文件夹/ trunk / {app1，app2，app3，app4}。
这使得分支/标记单个应用程序非常困难，因为您同时对所有4个应用程序进行分支，因此我们希望将其分为{app1，app2，app3，app4} / {trunk，标签，分支}但是我们遇到了放置共享库的问题？
我们不能将共享库作为SVN外部因素，因为当你分支/标记时，分支仍然引用了trunk共享库，而不是让它们分支。
任何提示？想法？
我们目前正在使用svn和cruisecontrol.net。
编辑：共享库现在经常发生变化，这就是为什么我们不能将它们作为svn externals用于trunk，因为我们可能会在分支中更改它们。所以我们不能将它们用作二进制引用。当库静态构建而不是包含源时，它也很难测试和调试。
答案 0 :(得分：6)
我想这一切都取决于共享库的稳定性。我倾向于将共享库视为他们自己的项目，与其他库一样在CruiseControl中构建。然后，四个主要应用程序将具有对共享库的二进制引用。
这种方法的主要优点是应用程序的稳定性，因为共享库是静态的。在将二进制文件显式更新为较新版本之前，对库的更改不会影响应用程序。分支带来二进制引用。你不会遇到看似无害的变化打破其他三个应用程序的情况。
答案 1 :(得分：4)
你能否澄清为什么你不喜欢同时分支所有四个申请？
这使得分支/标记单个应用程序非常困难，因为您同时对所有4个应用程序进行分支
我通常会将您的所有项目直接放在主干中，就像您目前所做的那样。然后，当我创建一个发布分支或一个功能分支时，我只是忽略了其他项目。请记住，这些副本很便宜，因此它们不会占用您服务器上的空间。
具体来说，这就是我如何布置你所描述的源代码树：
答案 2 :(得分：4)
我们正在启动一个开源项目来尝试解决这个问题。如果有人有兴趣评论或贡献它，那就是：
答案 3 :(得分：1)
我同意@Brian Frantz。没有理由不将共享库视为每天构建的自己的项目，并且您的项目依赖于每日构建的二进制依赖。
但即使您想将它们作为源依赖项并使用应用程序构建它们，为什么SVN外部方法不适合您？当您分支特定应用程序时，也不需要分支共享库，除非您需要为该分支单独复制它。但这意味着，它不再是共享库了，对吗？
答案 4 :(得分：1)
我的团队目前处于一个巨大的开发阶段，每个人基本上都需要在任何给定时间处理最新和最好的共享库。在这种情况下，我们在每个人的C：驱动器上都有一个名为SharedLibs \ Latest的文件夹，它自动与我们每个共享库的最新开发版本同步。应该从firehose喝的每个项目都有对此文件夹的绝对文件引用。当人们推出新版本的共享库时，各个项目最终会透明地接收它们。
除了最新的文件夹之外，我们还有一个SharedLibs \ Releases文件夹，该文件夹具有为每个共享库的每个版本命名的文件夹层次结构。随着项目的成熟并逐渐达到发布候选阶段，共享库引用将指向这些稳定的文件夹。
最大的缺点是这个结构需要到位才能构建任何项目。如果有人想在10年后构建应用程序，他们将需要这种结构。请务必注意，这些文件夹也需要存在于构建/ CI服务器上。
在执行此操作之前，每个解决方案都有一个lib文件夹，该文件夹位于包含二进制文件的源代码管理下。每个项目所有者的任务是传播新的共享dll。由于大多数人拥有多个项目，因此仍然处于非稳定阶段的项目经常出现问题。此外，TFS似乎没有跟踪二进制文件的更改。如果TFS更好地跟踪dll，我们可能会使用共享库解决方案/项目而不是我们现在采用的文件系统方法。
答案 5 :(得分：1)
它为14+版本控制系统（包括SVN）提供依赖管理（传递解析），强版本支持和自动标记/分支。
如果我需要详细说明，请给我一个提示。
我认为您无法避免将共享库作为单独的工件进行版本控制和分发，但是Maven可以帮助您完成这项工作！
你总是可以在一个解决方案中完成所有操作： - ）
示例工作流程：
如果您想提供压缩包作为构建的输出，Maven Assembly Plugin将帮助您实现这一目标。
答案 6 :(得分：0)
您可以在独立模式下使用Apache / IVY。
http://ant.apache.org/ivy/history/latest-milestone/standalone.html
我需要强调“独立”模式。如果你谷歌的例子....你会发现很多（而不是独立的）。
基本上，IVY就是在这个前提下工作的。
你发布二进制文件（或任何类型的文件，但我会说从这一点开始的二进制文件）.....作为二进制包很少。
下面是PSEUDO代码，不要依赖我的记忆。
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.4（＆lt;＆lt;其中.xml指的是组成一个包的N个文件。）
“包”仅表示一组文件。您可以在包中包含.dll和.xml和.pdb文件（我使用DotNet构建的程序集）。管他呢。 IVY是文件类型不可知的。如果你想在那里放置WordDocs，但sharepoint对于文档更好。
在对代码进行错误修复时，可以增加修订版本。
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.5
然后您可以从IVY中检索您想要的内容。
java.exe ivy.jar -retrieve PackagesINeed.xml
PackagesINeed.xml将包含有关所需包的信息。
等等 “我希望MyBinaryPackageOne版本为1.2+” （以xml定义）在构建框架二进制文件时......你发布到IVY。 然后，当您开发和构建代码时......您可以从IVY中进行检索。
在NUTSHELL中，IVY是FILES的存储库（不是源代码）。
Ivy然后成为你的二进制文件的权威来源。
“嘿，开发者 - 乔有我们需要的二进制文件”没有一种混乱。
.......
优点： 1.您不要将二进制文件保存在源代码管理中。 （因此不要BLOAT你的源代码控制）。 你有一个明确的二进制来源。 3.通过xml配置，您可以说出库需要哪些版本。 （在上面的示例中，如果MyBinaryPackageOne的版本2（2.0.0.0）发布到IVY（让我们假设从1.2.xy中断了更改）...那么你没问题，因为你在retrieve（xml配置文件）中定义了..你只想要“1.2+”。因此你的项目会忽略任何2 + ......除非你改变配置包。
高级： 如果您有一台构建机器（例如CruiseControl.NET）....您可以编写逻辑，在每次构建后将您的（新构建的）二进制文件发布到IVY。 （这就是我的工作）。
我使用SVN修订版作为内部版本号中的最后一个数字。 如果我的SVN版本是“3333”，那么我会运行这样的东西：
java.exe ivy.jar -publish MyBinaryPackageOne.xml --revision 1.2.3.3333
因此每当检索修订版“1.2.3+”的包时......我将获得最新版本。 在这种情况下，我会得到包的版本1.2.3.3333。
令人遗憾的是，IVY始于2005年（好吧，这是个好消息）......但NUGET直到2010年才出现？ （2011？） 微软在这个问题上落后了5 - 6年，恕我直言。
我永远不会回到将二进制文件放入源代码控制中。
IVY非常好。现在已经证实了。它解决了依赖性管理的问题。是否需要一点时间才能适应它？ 是的。
但最终还是值得的。
我的2美分。
.................
但是想法＃2是 了解如何将NUGET与本地（如公司本地）存储库一起使用。
这与IVY大致相同。
但看了NUGET，我仍然喜欢IVY。