Subversion 将主干合并到现有标签中

发布于 2024-10-15 03:19:54 字数 685 浏览 2 评论 0 原文

目前,我的 SVN 存储库中有以下设置:

-Root
--ProjectA
----trunk
----tags
----branches
--ProjectB
----trunk
----tags
----branches
--ProjectPool
----projectA
----projectB

其中 ProjectPool 包含 ProjectA 和 ProjectB 的特定标签。

现在ProjectPool中的标签会不时发生变化。这意味着 ProjectA 的特定主干版本已提交,我想从此修订版创建一个副本到 Root/ProjectPool/projectA。新标签应该取代旧标签,但应该有可用的历史记录。

这就像我的计算机上有一个我从不更改的分支,并且时不时地将主干合并到其中。但它应该完全在存储库上完成。 (无需签入/签出等)

这将允许我查看 Root/ProjectPool/projectA 的历史记录并查看它的更改。一种高级别的修订历史。

更新:
抱歉我忘了问一个明确的问题 -.-
在查看了到目前为止已经得到的答案之后,我想说 ProjectPool 中的项目副本是原始项目的分支。然后,只要我在 ProjectPool 中需要新版本,我就可以从主干合并它们。
现在的问题是,是否有一种方法可以“在线”进行合并,而不必先创建工作副本。

I'm currently having the following setup in my SVN-repository:

-Root
--ProjectA
----trunk
----tags
----branches
--ProjectB
----trunk
----tags
----branches
--ProjectPool
----projectA
----projectB

Where ProjectPool contains specific tags of ProjectA and ProjectB.

Now the tags in ProjectPool change from time to time. This means a specific trunk-version of ProjectA is commited and I want to create a copy from this revision into Root/ProjectPool/projectA. The new tag should replace the old tag, but there should be a history available.

Its like having a branch on my computer which I never change and from time to time merging the trunk into it. But it should be done on the repository completely. (without having to checkin/checkout etc)

This would allow me to look into Root/ProjectPool/projectA's history and see the changes of it. Kind of a high-level revision-history.

UPDATE:
I'm sorry I forgot to ask a clear question -.-
After viewing the answers which have been arrived until now, I would say that the copies of projects in ProjectPool are branches of the original projects. I then could merge them from trunk anytime I need a new version in ProjectPool.
The question now is, if there is a way to do the merging "online", without having to create a working copy first.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

回忆那么伤 2024-10-22 03:19:54

>>现在ProjectPool中的标签会不时发生变化。

标签是里程碑,它们不应该改变。您应该在每个版本上创建一个新标签。

>>这意味着 ProjectA 的特定主干版本已提交,我想从此修订版本创建一个副本到 Root/ProjectPool/projectA。新标签应该取代旧标签,但应该有可用的历史记录。

这里您需要的是 ProjectPoolProjectA分支,您可以将其与 ProjectA 的 >trunk。像这样的

  svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]

参考: http://svnbook .red-bean.com/en/1.5/svn.ref.svn.c.merge.html

>>这将允许我查看 Root/ProjectPool/projectA 的历史记录并查看它的更改。一种高级别的修订历史。

看起来您已经完成了目录结构。如果可能的话,我建议您遵循这个结构。

-Root
    +--ProjectPool
        +--ProjectA
            +----trunk
            +----tags 
            +----branches
        +--ProjectB
            +----trunk
            +----tags
            +----branches

您可以在 ProjectA 和 ProjectB 的 标签发布。更新的开发将在trunk中继续进行。对于任何侧面开发或现场发布,请在分支目录中创建一个分支。当分支完成后,将其合并回主干。这样您的主干将始终反映所有修订和更改。而且,这更方便(而且更传统)。

希望这有帮助。

>>Now the tags in ProjectPool change from time to time.

Tags are milestones, they should not be changing. You should create a new tag on each release.

>>This means a specific trunk-version of ProjectA is commited and I want to create a copy from this revision into Root/ProjectPool/projectA. The new tag should replace the old tag, but there should be a history available.

What you need here is a branch of ProjectA under ProjectPool which you can repetitively merge with trunk of ProjectA. With something like this

  svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]

refer: http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.merge.html

>>This would allow me to look into Root/ProjectPool/projectA's history and see the changes of it. Kind of a high-level revision-history.

Looks like you have gone ahead with your directory structure. I would suggest you to follow this structure, if possible.

-Root
    +--ProjectPool
        +--ProjectA
            +----trunk
            +----tags 
            +----branches
        +--ProjectB
            +----trunk
            +----tags
            +----branches

You can release ProjectA and ProjectB in their tags. Newer development will continue in trunk. For any side development, or spot release, create a branch in branches directory. When branch is done, merge it back to trunk. This way your trunk will always reflect all the revisions and changes. And, this is more handy (and conventional).

Hope this helps.

陌路终见情 2024-10-22 03:19:54

您实际上并没有提出任何问题,所以我不确定您是否知道 merge 子命令,但这就是您需要的:

特别注意--accept参数;您需要它才能自动解决冲突:

C:\>svn help merge
[...]
  --accept ARG             : specify automatic conflict resolution action
                            ('postpone', 'base', 'mine-conflict',
                             'theirs-conflict', 'mine-full', 'theirs-full',
                             'edit', 'launch')

我还建议阅读 分支和合并章节。

You don't really make any question so I'm not sure whether you're aware of the merge subcommand but that's the one you need:

Pay special attention to the --accept parameter; you need it in order to get automated conflict resolution:

C:\>svn help merge
[...]
  --accept ARG             : specify automatic conflict resolution action
                            ('postpone', 'base', 'mine-conflict',
                             'theirs-conflict', 'mine-full', 'theirs-full',
                             'edit', 'launch')

I also recommend reading the Branching and merging chapter in the Subversion book.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文