问题标签 [vendor-branch]

我们正在开发一个应用程序，其中包括：

• 合作伙伴不经常提供给我们的源代码库。这是一个有点工作的代码，是某些东西的“最终”版本（我们将它放在一个 zip 文件中）。他们有自己的发布周期和版本跟踪。
• 在上面的代码库上，我们进行了更改。这些可以是错误修复或新功能的开发。

到目前为止，我们设法创建了一些代码混乱，因此我们希望将所有这些都放在一个 SVN 存储库中。我想问你，你认为最好的做法是减少痛苦。

以下是我们认为重要的事情：

• 我们想跟踪我们的错误修复/更改，因为我们无法将错误修复发送回我们的软件供应商，但我们可以报告错误（他们可能会或可能不会修复它）。我们在他们的代码上开发的所有东西都是“内部的”，他们对我们的更改不感兴趣。
• 只要我们没有从供应商那里获得新的代码库，我们就会认为他们的最新版本是我们正在开发的稳定版本。这可能会进一步分支，但结果始终是稳定的主干，构建是基于这个“稳定”的主干完成的。
• 当供应商发布新版本时，我们希望将我们的“稳定”主干（包含大量更改）与其更改合并，从而创建一个新的“稳定”主干。
• 对于我们部署（到客户）的每个版本，我们应该能够稍后仅修复该版本上的错误，对于使用该特定版本安装我们系统的客户
• 有更多的开发人员在代码库上工作......（像往常一样:)

非常感谢您的提示。

我正在尝试使用 svn vendor 分支来升级第三方库。（我们修改了源代码）

我按照所有步骤创建了供应商分支::

为旧版本（第 3 方库）创建了供应商分支为最新版本（第 3 方库）创建了供应商分支，使用（使用 svn_load_dirs.pl 脚本）将最新版本复制到当前文件夹

svn中供应商存储库的结构

URL/vendor/library/3.5.0 URL/vendor/library/3.7.0 URL/vendor/library/current

我在 URL/trunk/library/customized-library 使用/修改了 library-3.5.0

当我尝试将 URL/vendor/library/3.7.0 和 URL/vendor/library/3.5.0 之间的差异合并到 URL/trunk/library/customized-library 时遇到问题

我在检出 URL/trunk/library/customized-library 的文件夹中，我使用以下命令进行合并

svn 合并 URL/vendor/library/3.5.0 URL/vendor/library/current 。--接受参数

当我使用 theirs-conflict 作为接受参数时，它会忽略我对旧版本的所有更改并在我使用 mine-conflict 时从 3.7.0 复制文件，当我使用延迟时它会忽略 3.7.0 中的文件，它会引发异常“树冲突”

谢谢吉安

我在存储库中安装了 Magento 企业版，客户端的站点正在运行，一切都很好。现在我想将此客户端升级到新版本的 Magento，但 EE 为我提供的升级的唯一帮助是删除整个app/code/core目录并将新文件移入。

至少可以说，这是非最佳的。

关于如何在干净地保留我的 SVN 历史记录的同时进行更改有什么好的想法吗？

谢谢，乔

是否可以在 subversion 中将 git 存储库作为“供应商分支”？

在这个项目中，我们将有几个部分，但有些部分会使用 svn，有些会使用 git。所以我正在寻找一个“项目根”，我们可以将其他项目作为供应商分支（或类似的）。

问题是是否有可能用颠覆来管理这个“项目根”？

谢谢约翰

反问题可以在这里找到：

• 是否可以在 git 中将 subversion 存储库作为“子模块”？

更新：

感谢 VonC 指出答案是“不，这是不可能的”。但反过来是（所以我可能会专注于这个问题）。

场景：购买的 Web 应用程序，供应商定期更新。然后，我们对外观进行大量定制，有时会添加我们自己的功能或在供应商得到它之前修复错误。对于版本控制，每次收到新版本时，我们都会按照他们的“供应商分支”</a> 模型使用 Subversion 。这还有一个额外的好处，那就是我们拥有他们系统的版本控制的普通副本。

问题：我们想切换到 Mercurial，并且可能会遵循稳定/默认的分支模式。如果我们只从供应商那里收到一个版本并从那里开始开发，那么 Mercurial 就非常有意义。但是，无论出于何种原因，我都无法思考如何处理来自供应商的未来版本。

请求：任何有关“供应商分支”Mercurial 风格的帮助将不胜感激。

我们有一个相当大的库，我们需要定期将其导入（然后修补）到我们的代码库中。

SVN Book 似乎推荐了一个“供应商分支”方案，我们在其中保留了“供应商丢弃”的修补版本。这会起作用，除了供应商也使用 SVN 并允许我们读取他们的 reop。

当我们需要更新补丁时，访问供应商文件的历史记录会很棒。

所以我的问题是：

有没有办法让修补的“供应商分支”也以某种方式保持对供应商文件历史记录的访问？

（我已经看到提到 svn:external 文件夹，但我不确定我是否真的了解挂钩修订的全部后果，也不知道我们将如何维护自己的补丁。）

在这里走的正确路线是什么？（FWIW，供应商每月发布一次。我们打算每年拉一次/两次更新。）

谢谢

旧进程是普通的svn vendor branch，但是我只将一个子目录复制到主代码库。因此对于：

被复制到：

然后我会添加新版本，标记它并将两个 library/Zend 文件夹之间的差异合并到 trunk/library/Zend

我如何在 Git 中做到这一点？

我的第一个想法是在哪里使用 git-svn 创建颠覆回购的 git 克隆，然后使用子树合并，但我不确定当目标实际上是外部回购的子目录时如何实现。老实说，我宁愿不合并所有其他目录，例如文档和测试。

我是否必须根据标签的子目录创建自己的 git 存储库，子树将其合并，然后通过在顶部下载新版本手动更新该 git 存储库，处理新目录，手动删除目录/文件我？

我想在 Mercurial 中存储一个项目，其中包含来自 Git 和 SVN 存储库的外部代码（可由我修改）。在 SVN 中，我会使用供应商分支来解决这个问题并复制代码，但我知道在 Mercurial 中，最好为不同的项目提供不同的存储库，并在需要时在它们之间拉取。

项目布局将是这样的：

在 Subversion 中，我会创建vendordir 和一个trunkdir，首先将所有外部库复制vendor到trunk. （我认为）我也可以在 Mercurial 中使用subrepositories执行此操作，但这是最好的方法吗？

我尝试为外部库设置不同的存储库，但似乎我无法将其拉入主存储库externalLibraryARepo的externalLibraryA目录？它进入主目录，这不是我想要的。我还可以创建一个 Mercurial 镜像存储库并将其作为子存储库包含在我的主存储库中，但是随后此子目录中的更改会转到镜像存储库，而我希望它们保留在主存储库中。

我有一个本地项目，我想使用 git 存储库作为版本控制软件。

由于我在 SVN 服务器上使用外部软件作为我的项目的基础，我认为最好的方法是将它作为我的 git 项目中的供应商分支，这样外部更改不会影响我的代码，我可以合并供应商分支不时在主干道上。

可以像这样混合git和SVN吗？什么是最好的项目布局，我如何实际合并主干中的供应商分支？

我的问题是，在按照以下程序合并时，在最佳实践方案中，“将分支折叠回主干”程序的最后一步是否是正确的方法？

我已经使用 svn 很多年了。在我的个人项目中，我总是很高兴地在trunk 上破解，并且在很长一段时间内以单行线性方式进行版本控制已经接近完美。简单高效。一切都很幸福，直到有一天我想要更多地控制 3rd 方库。

今天，我在一个项目中，我觉得已经超越了从树干直接破解的方法。我有多个 3rd 方库，其中一些每周都会更改，我确实需要对其中的内容进行更多控制。我需要能够查看 3rd 方库版本之间的特定变更集并跟踪我对特定库所做的更改。我见过几次代码库变得非常混乱，并且很难在没有经验的 buildmaster 的情况下恢复可用状态，我不能在时间上明智地在这里出错。

所以我研究了供应商分支，在这里和那里阅读了几篇文章。我有一本很棒的“带有 Subversion 的版本控制”一书，但我看到的例子有时在他们的方法上是矛盾的，我想理解“分支”。我正要遵循Evan Weaver 在这篇文章中给出的方法。

我在下面列出了程序，我关心的是最后一节“将分支折叠成树干”。似乎我过去合作过的 buildmasters 通常将分支变更集“合并”到主干上，我认为分支甚至没有被删除。这是一个正确的方法吗？

创建分支

1 - 注意当前的头部修订：

2 - 将主干的干净远程副本制作到分支文件夹中。给它起个名字。我们将其命名为 your_branch，将 HEAD_REVISION 替换为您在步骤 1 中记下的修订号：

3 - 切换您的本地结帐以指向新分支（这不会覆盖您的更改）：

4 - 检查您的本地结帐现在肯定是 your_branch，并且您可以更新确定：

5 - 如有必要，提交您的新更改。

更新分支

你已经在 your_branch 上开发了一段时间，其他人也在 trunk 上，现在你必须将他们的更改添加到 your_branch。

1 - 首先，更新您的分支结帐并提交任何未完成的更改。

2 - 搜索 Subversion 日志以查看您上次合并更改的修订号（或者原始分支何时创建，如果您从未合并）。这对于成功合并至关重要：

3 - 还要注意当前的头部修订：

4 - 将主干上的最后一个合并版本和主干上的头版本的差异合并到 your_branch 工作副本中，将 LAST_MERGED_REVISION 替换为步骤 2 中记录的修订号，并将 HEAD_REVISION 替换为步骤 3 中记录的修订号：

5.a - 在输出中查找错误。能找到所有文件吗？不应该删除的东西被删除了吗？也许你做错了。如果需要还原，请运行 svnrevert -R

5.b - 如果 5.a 中一切正常，检查冲突，解决任何发现的冲突：

6 - 提交合并，将 COMMAND 替换为步骤 4 中的确切命令内容：

将树枝折回树干

嘿，你的分支完成了。现在它必须成为主干。

1 - 首先，按照上一节中的每个步骤（“更新分支”），以便 your_branch 与主干上的任何最新更改同步。

2 - 完全删除中继：

3 - 将 your_branch 移​​动到旧的主干位置：

4 - 将您的工作副本重新定位到主干：

完毕！

请对此程序的任何建议、意见或反馈表示赞赏。