使用 TortoiseSVN 创建不带 /trunk 结构的分支
背景：我们的源代码保存在我们自己服务器的 SVN 存储库中。我们的 A 团队致力于网站的主要功能。我们希望与 B 团队在设计方面进行合作，但地点会有所不同。
很久以前，在设置 SVN 存储库时，我使用了一个最终可以访问的结构来创建它：
svn://www.myserver.com/main/abc
源代码文件位于“abc”级别及其下面的文件夹中。
直到现在我需要创建一个分支时，这对我们来说一直工作得很好。选择 TortoiseSVN → Branch/Tag 似乎给了我在以下位置创建分支的选项：
svn://www.myserver.com/main/def
但是，当我上次尝试时，它似乎在“abc”内创建了一个名为“def”的文件夹，这根本不是我所期望的。我希望创建一个完全独立的存储库副本，供 B 团队使用，并且当需要合并这两个副本时，这可以尽可能顺利地进行。
[我知道，当在“abc”中提交更改时，我们还必须在“def”中提交]
Background: We have our source code saved in an SVN repository at our own server. We have Team A working on the main functionality of the website. We are looking to work with a Team B on the design aspects which will be at a different location.
A long time back when setting up the SVN repository, I created it with a structure which was finally accessible at:
svn://www.myserver.com/main/abc
The source code files are present at the 'abc' level and in folders below that.
This has been working fine for us until now when I need to create a branch. Choosing TortoiseSVN → Branch/Tag seems to give me the option of creating a branch at:
svn://www.myserver.com/main/def
However, when I tried it last, it seemed to create a folder WITHIN 'abc' named 'def' which wasn't what I was expecting at all. I was hoping to create a completely separate copy of the repository which Team B could work on, and when it came time to merge the two - that could happen as smoothly as possible.
[I understand that when committing changes in 'abc', we will also have to commit in 'def']
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
svn 中的分支只不过是一个副本。如果您使用的接口赋予“主干”和“分支”名称特殊含义（从您描述的方式来看，TortoiseSVN 似乎就是这样做的），请尽量避免其分支功能，而直接创建一个副本。如果您查看 svn://www.myserver.com/main/，然后将 abc 复制到 def，则一切都已准备就绪。然后，B 团队可以查看 svn://www.myserver.com/main/def。
A branch in svn is nothing more than a copy. If you're using an interface that gives the name "trunk" and "branches" special meaning (and the way you describe it, it seems that TortoiseSVN does so), try to avoid its branching function and simply create a copy directly. If you check out svn://www.myserver.com/main/, and then copy abc to def, you're all set. Team B can then check out svn://www.myserver.com/main/def.
Hvd 答案的扩展版本
存储库布局只不过是关于使用树的接受的协议。您可以将主线和副工作存储在存储库树的任何位置，但它们不相交。
在您对存储库当前状态的描述中，您错过了一件重要的事情：存储库根在哪里，在哪个级别？ 两种情况“/main/”和“abc/”都是可以解决的，但步骤不同。
您可以使用 TSVN 的存储库浏览器轻松检测根甚至远程根。您可以访问 svn://www.myserver.com/main/ URL 作为存储库，否则您会收到错误消息？
第二个问题，与 repo-root 相关的是“TeamA 现在使用哪个 URL 来访问 repo？”是的，我阅读并理解
，但它为假设留下了一些空间：
（第一个版本和 svn://www.myserver.com/main 作为 Q1 的根目录将需要稍后重新签出存储库，以排除与 TeamB 空间相同的根）
恢复
查找存储库根，为我们编写它，无论如何我们都会概述后续步骤
Extended version of Hvd's answer
Repository layout is nothing more than accepted agreement about using tree. You can store mainline and side-work in any place of repository tree, while they aren't intersected.
In your description of current state of repo you miss one important thing: Where is repository root, on which level? Both situations "/main/" and "abc/" are solvable, but with different steps.
You can easy detect root even remote, using TSVN's Repository Browser. Can you access svn://www.myserver.com/main/ URL as repository or you'll get error?
Second question, related to repo-root is "Which URL TeamA use now for accessing repo?" Yes, I read and understand
but it leave some space for assumptions:
(first version and svn://www.myserver.com/main as root from Q1 will require later re-checkout repository in order to exclude common root with TeamB space)
Resume
Find Repo-root, write it for us, we'll outline next steps in any case