有一个(希望很小)关于 SVN 和检查 repos 的问题。基本上,我看到关于检查内容和时间的相互矛盾的教程和建议。有人会说:
svn co http://my.repos.com/project my_project
…而其他人则说:
svn co http://my.repos.com/project/trunk my_project
我什么时候想直接抢主干而不是整个项目?在过去,我从来没有遇到过任何一个问题,但我不确定是否存在一种比另一种更可取的情况。
最好的。
有一个(希望很小)关于 SVN 和检查 repos 的问题。基本上,我看到关于检查内容和时间的相互矛盾的教程和建议。有人会说:
svn co http://my.repos.com/project my_project
…而其他人则说:
svn co http://my.repos.com/project/trunk my_project
我什么时候想直接抢主干而不是整个项目?在过去,我从来没有遇到过任何一个问题,但我不确定是否存在一种比另一种更可取的情况。
最好的。
通常一个颠覆存储库有 3 个主要目录:
主干是代码的最新分支。
通常创建分支是为了开发您在主干中还不需要的特定功能。
标签就像主干的保存点。
如果您在项目的根目录下进行检出,您将获得所有分支、所有标签和主干。这可能会导致大量数据。
例如,如果每个代码版本都被标记,您将获得所有过去版本的源代码!
我希望这能帮到您
杰罗姆·瓦格纳
关于这一点,还有几点需要注意。
tags
(通常是树)包含假设的代码在特定时间点的不可变快照;这不是您想要更改的内容,因为大多数部署都将基于标签tags
树中提交更改,而不只是复制到其中,大多数 Subversion 客户端都会抱怨trunk
下目录的特例。branches
唯一显着的区别是它预计包含主要的发展路径正如其他人指出的那样,通常没有充分的理由检查整个项目,因为大多数时候您只在主干和一两个分支上工作,整个项目会占用大量磁盘空间。主要开发“分支”通常是您唯一需要的。
这是一个真实的例子。我们的团队针对主干进行所有代码更改。当我们需要一个 alpha(预完成)版本时,我们只需标记主干。一旦我们为给定的版本点击“代码完成”,我们就会创建一个代码冻结分支,在这里我们进行所有的版本更改。beta、RC 和 GA 版本是从该分支标记的。如果我们需要修补 GA 版本,则针对分支完成修补并合并到主干。这样,如果我们需要修补特定的东西,我们就不必担心更新的代码会泄漏到经过测试和批准的 GA 中。它还允许我们在代码冻结后立即开始开发软件的下一个版本。
此外,如果有一个主干带外的“副项目”,您可以为此创建一个分支并在准备好时合并它。
有些团队喜欢为每个 bug 创建一个分支,有些则直接在主干上工作(比如我的)。如果您的团队对每个分支进行错误处理,我永远不会检查整个项目。除其他外,我会看到很多我不关心的代码。
另外,关于存储库管理的一点,正如提到的@humble_coder
- 大多数 Subversion 工具在分支/标签管理方面都非常容易使用。例如,TortoiseSVN 有一个存储库浏览器,它允许您非常轻松地复制东西(创建分支和标签),甚至 svn 命令行工具也可以用来做与原子操作相同的事情(我们实际上有一个脚本创建 alpha 标签、代码冻结分支或冻结后发布标签)。
希望这可以帮助!
这取决于您如何布置存储库,但通常情况下,您将拥有以下结构:
/trunk
/tags
/branches
在tags
andbranches
中,您可能有多个项目副本(再次取决于您如何使用存储库)。
如果您的存储库以这种方式布局,并且您 checkout /
,您最终会得到几个代码副本(标签和分支),您可能不应该接触这些副本(例如标签)。
如果您/trunk
改为签出,您将只签出您当前正在使用的版本,这是您通常想要的。
我永远不会检查整个项目。通常,我一次只对一个分支感兴趣,可能两个,偶尔三个。我总是检查并更新后备箱。如果我需要检查已发布标签的操作(可能是为了调查错误),我会检查它,调查并删除。存储在其下的分支branches
通常具有更短的注意力跨度,也就是说,它们在短时间内被狂热地创建和使用,然后再也不会被触及。