svn子树，从一个回购更新，提交到其他

Question

在SVN存储库中有一个大项目。我想在其他应用程序中使用该项目的一些模块，所以我想从我的主要SVN存储库中检出它们，以便我可以更新我的代码。

如何“导出”我的存储库的一个文件夹/模块，以便我只能将该模块签出到其他项目？我希望包含该模块的其他项目也位于其自己的SVN存储库中。

在简历中，我希望能够对主repo执行SVN更新，但是要提交到项目repo。

我希望它清楚我想做什么。

针对DavidW anwser：

• 我有多个项目一个资料库，但如果需要的话我可能会改变这个 。
• 我想破解源代码。它的一个PHP项目。我在 分叉模块。 （我有一个全球通用的项目，如果我
  客户需要一些特定的功能，
• 我想创建一个客户端一个单独的项目（在SVN也分开），但我想
  有办法合并

Answer 1

几个问题：在主项目作出了
客户端项目的一些变化（全球bug修复或的funcionality前）：

• 你说的是多个仓库或多个p在相同的存储库中的对象？
• 如果你借用这个其他模块的代码，你保持它与其他模块同步，还是你分叉该模块？
• 你是什么真的想分享？您是否必须共享源代码或编译后的输出（Unix C/C +中的*.so或*.a，Java中的*.jar等）。

您要给出的答案很大程度上取决于您对这些问题的回答。

我们假设代码实际上是共享的。你在一方面做的是你想在另一方面完成的事情。您在您的项目中进行更改，其他项目中的代码也会更改。

在这种情况下，请使用svn:externals。这是放置在目录上的属性。它所做的是将Subversion URL与子目录名称相关联。例如：

$ svn propset svn:externals "http://svn.vegibanc.com/svn/trunk/project/stuff utils" . 

将属性放在当前目录中。当您进行更新或结账时，您的项目中将创建一个名为utils的目录，并且Subversion将自动检出http://svn.vegibanc.com/svn/trunk/project/stuff到该目录中。这很神奇，但像所有的魔法一样，它既有明亮的一面，又有黑暗的一面。

首先光侧的：

这两个项目之间共享代码。您在utils目录中进行更改并提交更改，并且将更新project中的stuff子目录。我使用它来将工具构建到我的项目中。如果我升级该工具，所有项目都会获得升级的工具。现在

，黑暗的一面：

如果定义了svn:externals就像我给你，你会懊悔不已。想象一下，如果你决定分发你的作品发布。那么，你的utils目录仍然指向project/stuff的trunk。如果你分支2.1版，而trunk现在在2.2上工作，你会得到你不想要的东西utils。

更糟的是，如果您创建了一个标签，该标签将继续发生变化，因为trunk中的utils目录仍在更改中。

因此，强烈建议您指定一个确切的版本一个URL：

$ svn propset svn:externals "-r23283 ^/trunk/project/stuff@23283 utils" . 
$ svn propset svn:externals "^/tags/2.3.3/project/stuff utils" . 

在第一阶段，我指的是一个特定修订的URL。这是完全不变的。如果我需要将其指向另一个修订版本，则需要更改svn:externals属性本身。

第二个是指向一个特定的标签。它不是安全因为标签可以改变，但我可以把我的外部依赖作为释放这种方式。我正在使用版本2.3.3的东西实用程序。

两者都使用^快捷方式，它只是表示Subversion存储库根。这样，如果你将你的Subversion版本库移动到另一个系统，或者从http改为svn，你的外部设备仍然可以工作。 当然，如果您这样做，您将永远无法更改svn:externals下的代码。而且，这不是你想要的。

您也可以使用相对网址，但他们关心更危险一点。

想象一下你的两个项目就是这样，和你想的东西目录的svn:external链接utils的目录：

http://svn.vegibanc.com/svn/trunk/project/foo/stuff 
http://svn.vegibanc.com/svn/trunk/project/bar/utils 

该项目支在一起，一起标记。你可以这样做：

$ co http://svn.vegibanc.com/svn/trunk/project/bar bar-trunk 
$ cd project-bar 
$ svn propset svn:externals "../foo/stuff utils" . 

这将外部链接东西目录到utils的目录。但是，它是以相对的方式完成的。如果你这样做：

$ cp http://svn.vegibanc.com/svn/trunk http://svn.vegibank.com/svn/branches/2.3 

你utils的目录仍然会被外部链接给foo的项目下的东西目录，但他们都将是在2.3分支。

更改中的代码将更改foo/stuff中的代码，反之亦然。您仍然在共享代码，但两种项目仍处于同一分支中。

后来，如果您标记是这样的：

$ cp http://svn.vegibank.com/svn/branches/2.3 http://svn.vegibank.com/svn/tags/2.3.0 

您的代码2.3.0不太可能改变，因为外部链接，它们链接到全部由该标签包裹的东西。

以上假设您正在共享代码，并且任一项目中的更改都会影响其他项目。

更好的方法是为foo创建可存储在发布服务器上的某种类型的编译对象（如JAR文件或* .so）。您将此编译对象视为自己的项目，并使用其自己的版本，并且您的项目将取决于此对象的特定版本。不幸的是，这并不总是奏效。

如果您只是分支代码，请将svn cp从存储库中的一个位置移动到另一个位置。您可以在不影响其他项目的情况下进行更改，反之亦然。更好的是，您可以在两个位置之间来回地合并更改，以使它们保持同步。

希望这回答你的问题。如果你可以扩大你的问题，并给我们更多关于你想要什么的细节，我将能够更新我的答案。

Answer 2

• 如果你想使用Subversion版本库的共享代码 - 它的SVN：外部组件
• 如果你想从主线上共享代码端口更改成共享代码客户特定的版本 - 这是“卖主分支”在SVN行话

组合a）和b）会给你所需要的结果

1. 选择一些节点（客户的仓库外主干），其中你会链接到共享节点的DEV-回购
2. 创建外部定义（首选PEG修订版，如果在提交到dev-repo之后必须手动更新定义的成本，则必须有简单的时间返回）
3. 将节点复制到位置，其中必须在现场项目（svn cp ...）
4. 代码...
5. 当你在DEV-回购的变化，要转移到客户回购 - 更新的外部对需要修订，合并“供应商”节点“活”

样品：

如果您“会在客户的回购

• /供应商/ lib目录（其中lib是从国外回购目录） * /主干/ common/lib目录（客户版以上的lib）

名

从LIB-主线将更改合并从/供应商/ lib添加/主干/ common/lib目录（在工作拷贝的相应节点的主干）

大卫的有关的外部笔记仍然有效的，正确的和有益的合并