我目前正在测试服务器上安装和配置一个开源项目。我受过良好的源代码管理培训，我想确保我所做的一切都得到妥善管理（对于我，唯一的开发/管理员，以及未来的维护者）。开源项目可作为源代码下载或通过 svn checkout 获得。
我想拥有自己的项目源代码控制版本。我不打算过多地更改（java servlet）代码（如果有的话），但是我肯定希望对所有涉及的配置、XML 文件、XSL、CSS 等进行源代码控制。
我应该继续做我自己的所有源代码的本地存储库吗？我应该尝试只控制我需要更改的文件吗？在这种情况下，我希望目录结构匹配，所以我可以直接对构建目录进行检查。
我会检查所有代码，因为即使您不想更改它们或现在看不到理由，其他人稍后可能会看到原因。此外，可能存在错误，或简单的重构以提高可维护性或性能等。
SVN 的基本布局是：
branches/
tags/
trunk/
并且一般目录布局（在这三个之下）当然应该与您的应用程序相匹配，以便您可以检查它并立即运行它。但是，您可以通过构建文件等进行轻微修改。但我想checkout and go总是很好。有关更多信息或最佳实践的建议，我会查看使用您的技术的其他开源项目。
至于配置文件 - 我不会签入。大多数项目都会签入一个foo-dist向用户显示所有配置选项的文件。至少，他们需要复制foo-dist到foo以启用默认配置。
此外，您是否查看过用于项目托管（包括版本控制）的Google Code、Sourceforge或github ？所有这三个都免费为您提供大量服务-在您无需为项目托管等服务的服务器方面也是免费的。
对同一个目录树进行两次签出是行不通的。如果您检查您的源代码，并尝试检查 OSS 项目源代码，那么它们的任何共同目录都会失败，说它已经是另一个项目的工作目录。
如果你可以将css、xml、xsl等文件集中到一个公共目录中，你可以将它们放在你自己项目的svn中的一个目录中，然后将它们检出到OSS项目的工作目录中的一个目录中。
~/Working => svn://samhoice/project/trunk
~/Working/osscomponent => svn://osshost/project/latesttag
~/working/osscomponent/config => svn://samhoice/project/trunk/config
在这种结构中，samhoice 的 svn 存储库中不存在 osscomponent 目录。它由您的安装脚本添加为 OSS 项目的工作目录根目录。config 目录没有从 OSS 项目中检出，也不存在。config 目录由您的安装脚本创建，并且 config 目录从您的项目存储库中签出。
所以在这个目录结构中你有三个结帐。没有递归重叠，因此任何子目录上的 svn 映射之间都没有冲突。
如果您需要将配置文件安排在 OSS 项目的结构中，请在您的 makefile 或配置脚本中添加一些符号链接。您也可以在 svn 客户端的结帐后挂钩中执行此操作。
我在我的一个项目中使用了这样的结构，用于在两个项目树之间共享一些代码。共享内容位于我为您的配置部分推荐的子树中。
我使用了几种方法，具体取决于第 3 方项目的大小和定制量：
对于小型或高度定制的项目，我将从股票代码开始检查整个项目。这使得整个项目的工作变得容易，并提供“一站式购物”来检查我构建它所需的一切。
对于大型或略微定制的项目，我会保留一份库存档案的副本（通常是一个.tar.bz2或.zip文件）并确保它已备份。然后，我将以某种形式将体现我的定制的文件置于修订控制之下。这里的选项是
（仅）签入自定义文件本身。如果您正在修改源代码，这通常是最佳选择。
签入执行自定义的脚本。如果脚本向配置实用程序提供输入，这是最有效的，因为您将自定义（输入数据）与库存件（配置实用程序）分开存储。如果发布了第 3 方库的新版本，通常很容易将您的自定义应用到它，从而允许进行关键升级。
对于“永远不会改变™”的项目，或者客户通过合同将您绑定到特定版本的项目，请将库存代码存储在某处，并在修订控制下创建补丁文件。然后，您可以发布带有补丁的“已批准”版本。 注意：这是一个相当糟糕的选择，因为补丁文件很难维护——如果你制作了一个新补丁，你必须要么重新创建补丁文件，要么创建一个额外的补丁，应用在第一个补丁之上。选择此选项的原因通常不是出于技术原因而选择的。
我怎么强调都不够，你需要记录构建此类项目和添加自定义项的整个过程，或者自动化它，或者（最好）两者兼而有之。 忘记哪些文件属于哪里或属于谁非常容易，而且重新开始很痛苦。特别是如果你是继承人。
祝你好运！