我遇到一个问题,每当我使用TortoiseSVN从trunk创建一个分支时,所有提交到该分支的提交也会在我更新后显示在我的trunk文件夹中,反之亦然。
我的工作是:
如何断开此链接 - 或者创建一个分支而不将其与1:1与trunk链接?
我找到的唯一解决方案是复制整个trunk文件夹并再次添加每个文件;虽然这不是必要的。
答案 0 :(得分:3)
根据您对其他答案的评论,您似乎无法有效地使用SVN。我认为这是你问题的根源。
听起来您的工作副本是项目根目录,在您的计算机上,您可以看到每个分支,每个标记以及主干。当您进行更新时,您将在根项目中进行更新,并在每个分支中进行每次更改。
这不是SVN的用途。
预期用途是检查每个感兴趣分支的一个工作副本。如果您正在使用干线,请检查干线。如果您正在使用功能分支,请查看该分支。您可以为多个任务创建多个工作副本。
你现在的方式,如果你的项目变得非常庞大,有大量的分支和标签,你可以在查看顶级文件夹时占用千兆字节的空间,每个操作都会需要很长时间才能完成。
为什么这与您的问题相关?这就是我认为发生的事情:
现在,由于您选择切换行李箱文件夹," trunk"在您的计算机上不指向SVN存储库中的实际trunk文件夹。它指向分支。这就是为什么你看到" trunk"在你的机器上。如果你进入存储库浏览器,我希望你不会在trunk中看到你的分支发生变化。如果你"切换"你的行李箱文件夹回到行李箱,你应该看到你的变化从你机器的行李箱上消失了。
要在将来避免这种情况,请:
答案 1 :(得分:2)
下面的场景显示了该文件夹上的本地文件夹结构和关联的SVN命令(缩进文件夹是子文件夹)。此外,为简洁起见,我只显示主干和分支文件夹(标签文件夹未显示)...为了讨论起见,可以添加和处理标签文件夹与分支文件夹完全相同。
情景A
这就是O.P.似乎在使用SVN的方式:
Project << svn co http://server/svn/Project
trunk
branches
branch1
branch2
...这将检出整个存储库的完整副本(主干加上所有分支以及所有标记)。做一个&#34; svn开关&#34;除了&#34;项目&#34;以及任何子文件夹。会引起混淆,因为(原创)&#34;工作副本&#34;已经在&#34;项目&#34;你最终会在同一棵树的两个不同文件夹中找到两份工作副本。因此,Ben上面提到的永不改变的建议是有道理的。尽管如此,如果您从未切换(子文件夹),则使用此工作流程完全有效。
情景B
这就是Ben在上面讨论的内容(&#34;更改了你结账的深度&#34;):
...if you want to work on the trunk:
Project << svn co http://server/svn/Project/trunk
...if you want to work on branch2:
Project << svn switch http://server/svn/Project/branches/branch2
...因此,一个文件夹(&#34; Project&#34;)会随着时间的推移更改其上下文,因为您每次都会执行svn checkout或svn切换到其他URL。但是知道本地文件夹的工作上下文并不是很明显。在TortoiseSVN中,您可以右键单击并选择&#34; Switch&#34;查看当前的URL(然后取消开关)或使用&#34; svn info&#34;从命令行,但这些是额外的步骤。尽管如此,听起来这是使用SVN的一种非常常见的方式。
情景C
这是方案B的一个变体,David W在上面讨论过......这种方法使得(在视觉上)哪个主干/分支/标签正在处理更加明显:
Project_trunk << svn co http://server/svn/Project/trunk
Project_branch2 << svn co http://server/svn/Project/branches/branch2
...并且永远不要对上面的本地文件夹进行svn切换,因为这会引起混淆(例如,在Project_branch2上发出&#34; svn switch http://server/svn/Project/trunk&#34;会使本地branch2文件夹保持不变回购行李箱的内容)。无论如何,这种方法确实使视觉上明显地显示了本地文件夹包含的内容。
情景D
这是方案A和C的混合,它将顶级文件夹下的所有主干/标签/分支包含在项目名称中,模仿仓库上的结构:
Project << (no SVN checkout performed on this folder)
trunk << svn co http://server/svn/Project/trunk
branches << (no SVN checkout performed on this folder)
branch1 << svn co http://server/svn/Project/branches/branch1
branch2 << svn co http://server/svn/Project/branches/branch2
在这种方法中,您可以通过避免在&#34; Project&#34;上避免SVN签出来避免抓取整个仓库,并且通过避免在文件夹&#34;分支&#34;上的SVN签出来避免抓取所有分支。 。因此,它就像Scenario C一样选择性地检查分支或主干,但它仍然像场景A中那样反映了repo的结构。我提出这是因为这是我可视化本地结构的第一种方式之一(作为远程结构的镜像以保持一致性)。我喜欢它如何反映存储库中的结构,但如果这样可以提高工作流程的清晰度,那么这是有争议的,因为你必须记住&#34;特殊规则&#34;避免结账并打开文件夹&#34; Project&#34;和&#34;分支&#34;。
我(自以为是)的结论是,最明显的工作流程是上面的B和C,因为它们没有必须记住的特殊情况,但如果适合你,肯定可以使用A和D.无论如何,通过这些场景帮助我可视化和理解如何处理主干,标签和分支。希望它能帮助别人!
答案 2 :(得分:1)
我认为你误解了Subversion(特别是TortioseSVN)是如何工作的。
在Subversion中,当您执行 checkout 时,您将创建一个工作目录。当您在分支的工作目录上执行更新时,您正在将该工作目录更改为您的分支(如果我了解您的工作流程)。主干不会被改变,只是你的工作目录。
Subversion的一个优点是很容易拥有多个工作目录。 (您可以在Git中,但最终会得到整个存储库的多个副本)。因此,为每个分支单独检查。我有一个名为workdir
的目录,在此之下,我的所有分支都在其自己的目录中(workdir\trunk
,workdir\foo
等。)这样,我不会混淆了哪个分支或主干在我的工作目录中。
答案 3 :(得分:0)
每当你在Tortoise中创建一个分支时,它会询问你是否要切换到分支或保留在主干中,如果你没有切换你提交的所有更改仍然会被提交到主干...
此外,Update将使用服务器版本更新您的本地文件,并且commit会将您的文件发送到服务器(如果您切换到服务器文件夹,主干或其中一个分支)