我们的开发使用了大量的开源代码，并试图找出管理这些外部依赖关系的最佳方法。如何管理不断被修改的外部依赖关系
我们目前的配置：
我的问题
，如果我需要修改外部代码怎么办？ 目前我在我的svn仓库中创建了一个名为extern_hacks的文件夹，这是我放置修改的外部代码的位置。然后，我将这些文件链接（或在Windows上复制）到外部目录结构中。这个解决方案是有问题的，因为很难跟踪复制文件，并且当文件位于两个存储库（我的修改文件和原始存储库说sourceforge）时很难从svn更新。
如何管理外部依赖的版本？
我很感兴趣地听到别人如何处理这些问题。谢谢。
我让他们在SVN，并管理为vendor branches。保持它们外部松散使得很难回到以前的版本，或修复以前的版本中的错误（特别是如果错误来自于对外部依赖性的改变）
保持它们在svn中为我节省了很多头痛，并且还可以让你获得一个能够快速处理你的代码库的新工作站。
我知道我有点晚了，但作为对这个答案的评论，我想提一下简单的规则：应该保持构建（源代码，构建脚本）和部署（映像，资源文件）过程所需的所有内容在你的scm。 – JohannesH 2010-02-02 21:36:27
我不明白你为什么说
我不想把它们放在我们的仓库，因为我不能够更新他们的方式。其中一些不断更新。
你真的需要
包括在你的源代码控制的外部依赖，并定期更新它们，然后TESE，测试，再测试。
协调您的构建过程和外部依赖关系的更新。
如果你的代码依赖于一些东西，那么你真的需要了，当它被更新/修改为具有控制权。在任何时候对这些依赖关系进行更新的空间进行编码太痛苦，因为您无疑会发现。我个人比较喜欢的选项1.
我同意没有必要为此维护一个单独的存储库。如果需要分离，请使用分支。 – JohannesH 2010-02-02 21:39:19
你有没有考虑Maven？这是一个构建系统，对管理依赖关系具有出色的支持。对于每个项目，您都可以在xml文件中指定所需的依赖项作为该项目的一部分。外部库被保存在一个依赖库（在我们的例子中为Artifactory），这与版本控制系统是分开的，可以只是一个网络驱动器。它还允许管理不同版本的项目。
当我不得不这样做时，我将外部源添加为外部源，然后对其应用修补程序。该补丁包含我对外部源的修改。所以，我其实只是版本控制我的补丁。大多数情况下，如果外部代码没有“戏剧性”的变化，这种情况就会起作用。
我会小心考虑Maven的，因为：
现在与第三方打交道时，你可以考虑让它们在你的版本控制系统，但在包装方式：这是一个非常紧凑的方式，来源及文件压缩，以尽可能少的文件数量。
这样的话，你会管理这些（多）的第三方库的部署因为文件的数量来部署低容易。
另外，让它们在源代码控制下可以让你创建一个分支（比如'hack'分支），在这个分支中你将存储被黑客入侵的库的打包（或压缩）版本。
您可以在外部方式存储什么是未压缩的，完整的代表这些库文件，因为没有对他们没有真正的发展，或者只是一个守黑客：通常情况下，你的工作是不发展现有库，但要使用它们（即使有点修改），以便更快地实现项目的某些功能。
如果您需要在某些时候将某些被黑客入侵的版本与某些官方版本进行比较，您只需从svn中拔出相应的“被黑”版本号，将其与官方（和外部存储的）进行比较，版本（例如winmerge）
为什么你不能更新他们，如果他们在回购？这是没有意义的。请解释。 – Mecki 2008-10-07 16:40:25