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