Tortoise SVN - 如何让我的回购准备好

时间：2014-02-25 21:25:43

标签： svn version-control merge tortoisesvn trunk

我有一个SVN存储库设置，但我没有定义我的主干，我对如何将代码从一个分支移动到另一个分支有点困惑。

结构如下：

--Repo
----Dev
------common
------project
----Test
------common
------project
----Prod
------common
------project

首先，哪一个应该是后备箱？我当时认为Test分支应该是，但最后我准备好说Dev分支应该是（虽然那个例子只有两个分支）。其次，所有代码已经在3个分支中的每个分支中，我是否需要，如果是，如何将其中一个声明为主干？

最后，当准备将代码提升到我们的测试分支时（这将通过Windows资源管理器完成，而不是从Visual Studio / Xcode项目等完成。我是否只需点击分支，进行SVN更新，SVN合并并选择要合并的源？

很抱歉有新问题，令人惊讶的是我在SO上找到的所有内容都适用于可能/可能不适用的不同场景，我只是想确认让我感觉更好所以我不必重做所有这些在路上。

编辑（响应David的回答）

好的，所以我已经在公共文件夹下面有“trunk / branches / tags”。所以我猜我可以完全删除Dev / Test / Prod文件夹（以及prod的内容）。 “测试”实际上将存放在Repo / foo / 分支 / test中，这是正确的吗？或者我猜它可以去Repo / branches / test / foo /，对吗？ （常见的是设置为SVN外部... fyi）

由于我根本没有使用过SVN语法，我需要去研究 - 父母的事情...我们只使用Tortoise，但我想我可能还是需要学习SVN，因为这是使用Jenkins构建...

你的答案中的其他一切看起来都很棒！我只有一点Git背景，有很多SourceGear Vault背景，所以转换仍然有点令人困惑。

2 个答案:

答案 0 :(得分：1)

trunk / tags / branches只是命名约定。我建议你开始使用主干，然后在准备发布时合并测试。为清楚起见，您可以将Dev分支重命名为“trunk”，这样您就不会感到困惑的共同开发人员。

Prod分支看起来有点矫枉过正;您可以在测试分支中标记已投入生产的版本。

答案 1 :(得分：1)

您不需要为测试，生产和开发分别设置代码行。除非您希望 Test 和 Production 中的用户自行编码。否则，你会来回复制很多东西。

开发人员正在进行的修订（让我们说Subversion修订版＃100）稍后将由QA团队进行测试。而且，如果QA团队喜欢它，那么修订版＃100将会被发布到Production中。每个团队都跟随另一个团队也许那些正在开发中的人正在研究Subversion修订版100.同时，QA正在测试修订版97.而且，修订版90正在生产中。我唯一建议的是标记投入生产的内容。

让我们采取典型的结构：

repo/branches/
repo/tags
repo/trunk/common
repo/trunk/projects

我在项目foo上工作。我查看repo/trunk/foo和repo/trunk/common完成我的工作并检查我的更改。

现在，让我们说我希望将标签版本90从我的主干中删除，因为它已被批准用于制作，我可以标记我的版本如下：

$ svn cp --parents -r 90 $REPO/trunk/foo@90 $REPO/tags/1.3/foo
$ svn cp -r 90 $REPO/trunk/common@90 $REPO/tags/1.3/common

如果我需要查看发布的内容，我可以从我的存储库中查看1.3版本标记。

通常使用分支的方法有两种：

  • 你在发布时分支。
  • 您分支功能。

我将描述发布分支，因为它更容易。

想象一下，您正在开发1.3版本。在某些时候，你的一些开发人员在你的1.3版本上没有更多工作要做，并希望在1.4版本上工作。

到目前为止，1.3版本的工作正在中继上完成。您的1.4开发人员无法完成他们的工作，因为他们不想在您进行1.3代码更改时进行1.4更改。因此，他们整天都在玩Candy Crush，直到1.3完成，并且每个人都可以在1.4版本的时候离开行李箱。

为了减少Candy Crunch时间，我打算发布发布分支：

$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.3/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.3/common

现在，那些仍在开发1.3版本的开发人员将他们的工作副本切换到1.3分支，而那些在1.4上工作的人仍在继续工作。一旦您的发布完成，您可以直接在分支上标记它：

$ svn cp --parents $REPO/branches/1.3/foo $REPO/tags/1.3/foo
$ svn cp $REPO/branches/1.3/commons $REPO/tags/1.3/commons

当1.4版接近时，您需要冲洗并重复。

$ svn cp --parents $REPO/trunk/foo $REPO/branches/1.4/foo
$ svn cp $REPO/trunk/common $REPO/branches/1.4/common

现在，那些在Release 1.5上工作的人继续在trunk上工作，而那些在Release 1.4上工作的人则在分支机构工作。

如果您需要进行 hotfix ，该怎么办？说1.4版本中有一个错误？您已经拥有1.4分支，我认为在1.4版本发布时不再使用它（它很容易检查。将1.4分支上的最新版本与制作1.4代码的修订版进行比较）。只需在1.4分支上完成1.4.1版本的工作。

如你所见，它并不是那么复杂。顺便说一下，你也没理由不反转这些名字：

$REPO/foo/trunk
$REPO/foo/branches
$REPO/foo/tags

$REPO/common/trunk
$REPO/common/branches
$REPO/common/tags

在这种情况下，我将每个项目视为一个单独的子存储库，并具有自己的分支和标记。如果我的所有项目都在不同的发布时间表上，我可能想要这样做。

响应

  

好的，所以我已经拥有＆＃34; trunk / branches / tags＆＃34;在公共文件夹下面。所以我猜我可以完全删除Dev / Test / Prod文件夹（以及prod的内容）。 ＆＃34;测试＆＃34;实际上将被安置在Repo / foo / branches / test中，这是正确的吗？或者我猜它可以去Repo / branches / test / foo /，对吗？ （常见的是设置为SVN外部... fyi）

不需要测试分支。 QA只是在开发人员正在使用的分支上测试特定的Subversion版本。例如，让我们说Subversion在修订版100上，而QA正在测试修订版95.如果QA发现了一个错误，它会被报告并合并到修订版101中。当QA测试修订版101或更高版本时，他们可以测试看看如果该错误已得到修复。如果有，他们可以关闭bug。否则，他们可能会重新打开它。

如果您使用像Jenkins这样的持续集成系统， 您的软件，那么您可能会谈论特定的构建。最后一次构建将是Build＃30，但QA正在测试Build＃28。如果质量检查发现了一个错误，开发将只是修复它，詹金斯将生成Build＃31。然后QA可以测试Build＃31以查看错误是否已修复。

我们在一家商店中使用了Jira和Jenkins，这些都是集成的。当开发人员修复错误时，他们会将该错误号放入提交消息中。然后Jenkins将使用Jenkins构建更新该Jira票证。如果QA发现了修复问题，他们可以查看Jira票证，查看Jenkins构建已修复的位置并对其进行测试。

我希望这是有道理的，为什么你不需要分支进行测试，制作等。

  

由于我根本没有使用SVN语法，我需要去研究 - 父母的事情......我们只使用Tortoise，但我想我可能需要学习SVN无论如何，因为这是使用Jenkins进行构建...

了解Subversion客户端的命令行版本总是很好。有时，当TortoiseSVN出现问题时，您可以从命令行客户端获取更多信息，以查看正在进行的操作。 --parents参数仅表示创建可能存在或不存在的父目录。例如，您要创建目录/branches/4.3/foo，但可能没有/branches/4.3目录。在TortoiseSVN中，我相信这将自动创建。在命令行客户端中，--parents参数将同时创建/branches/4.3目录（如果它不存在）和/branches/4.3/foo目录。

  

你的答案中的其他一切看起来都很棒！我只有一点Git背景，有很多SourceGear Vault背景，所以转换仍然有点令人困惑。

与Git相比，Subversion实际上非常简单，因为只有一个级别的存储库。您结帐，修改，提交。

Git与SVN的最大区别在于SVN是线性的。修订版100总是在修订版101之前。在Git中，修订版没有真正的订单。存储库修订表示为带有校验和的 blobs 。该命令由指向特定 blob 的树强加。但是，熟悉SVN的人比其他人更难理解Git。

  

等等，还有一个问题，如果分支名称要更改每个版本（即1.3,1.4等），我将如何自动化我的测试环境的构建？

在Jenkins中，我们只是有一堆复制项目的shell脚本。我已经设置了项目，因此它们之间的变化很小：我只是更改了分支名称。运行我的脚本，然后创建更多Jenkins作业。运行另一个，删除旧的分支作业。

某些网站使用提交后触发器来构建在分支上发生的Jenkins作业。在Jenkins中，您可以将参数传递给构建，因此您可以传递发生更改的分支，并且Jenkins构建在该分支上。当他们从一个版本移动到另一个版本时，他们永远不必创造新的工作。

现在，如果您每周或每两周发布一次，您可能不需要发布分支。一切都离开了行李箱（除了偶尔的热补丁）。在这种情况下，您团队中的每个人都很可能正在使用同一版本。我分支是为了允许两组不同的开发人员同时使用版本1.3和1.4（在主干上）。如果您没有遇到这个问题，则不需要发布分支（除了偶尔的热修复）。

相关问题
最新问题