我什么时候应该在 SVN 存储库中查看 TRUNK 与 FULL PROJECT？
有一个关于 SVN 和检查存储库的（希望是小问题）问题。基本上，我看到关于检查内容和时间的相互矛盾的教程和建议。有些人会说：
svn co <a href="http://my.repos.com/project" rel="noreferrer">http://my.repos.com/project my_project
…而其他人则说：
svn co <a href="http://my.repos.com/project/trunk" rel="noreferrer">http://my.repos.com/project/trunk my_project
我什么时候想要直接抢主干 vs 整个项目？过去我从来没有遇到过任何问题，但我不确定是否存在其中一种比另一种更好的情况。
最好的。
Got a (hopefully small) question regarding SVN and checking out repos. Basically I see conflicting tutorials and suggestions regarding what to check out and when. Some will say:
svn co http://my.repos.com/project my_project
…while others say:
svn co http://my.repos.com/project/trunk my_project
When would I want to grab the trunk directly vs the entire project? In the past I've never had trouble with either, but I'm not sure if there are scenarios where one is preferable to the other.
Best.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
关于这一点还有其他几点需要注意。
tags树（通常是一棵树）包含假设的不可变的代码在特定时间点的快照；这不是您想要更改的内容，因为大多数部署将基于标签tags树中提交更改，而不是仅仅复制到其中，大多数 Subversion 客户端都会抱怨trunk是branches下目录的特例；唯一显着的区别是它预计包含主要开发路径正如其他人指出的那样，通常没有充分的理由检查整个项目，因为大多数时候您只在主干和一两个项目上工作分支，整个项目会占用大量磁盘空间。主要开发“分支”通常是您唯一需要的东西。
这是一个现实世界的例子。我们的团队针对主干进行所有代码更改。当我们需要 alpha（预完成）版本时，我们只需标记主干即可。一旦我们为给定的版本点击“代码完成”，我们就会创建一个代码冻结分支，在其中进行所有版本更改。 Beta、RC 和 GA 版本均来自该分支。如果我们需要修补 GA 版本，则修补程序会针对分支完成并合并到主干。这样，如果我们需要修补特定的内容，我们就不必担心新代码会泄漏到经过测试和批准的 GA 中。它还允许我们在代码冻结后立即开始开发软件的下一个版本。
另外，如果有一个主干带外的“副项目”，您可以为其创建一个分支，并在准备好时合并它。
有些团队喜欢为每个错误创建一个分支，有些团队直接在主干上工作（比如我的）。如果你的团队对每个分支进行错误处理，我永远不会检查整个项目。除此之外，我会看到很多我不关心的代码。
另外，还有一点关于
@humble_coder提到的存储库管理 - 大多数 Subversion 工具在分支/标签管理方面都非常易于使用。例如，TortoiseSVN 有一个存储库浏览器，允许您非常轻松地复制内容（创建分支和标签），甚至 svn 命令行工具也可以用于执行与原子操作相同的操作（我们实际上有一个脚本创建 alpha 标签、代码冻结分支或冻结后发布标签）。希望这有帮助！
There are a couple of other points to note about this.
tagstree (and it will usually be a tree) contains hypothetically immutable snapshots of your code at a specific point in time; this is not something you want to change, as most deployments are going to be based on tagstagstree, instead of just copying into ittrunkis a special case of the directories underbranches; the only significant difference is that it is expected to contain the main development pathThere is usually no good reason to check out the entire project, as others have pointed out, as most of the time you are only working on the trunk and one or two branches, and the entire project can eat a significant amount of disk space. The main development "branch" is most often the only thing you need.
Here's a real-world example. Our team does all the code changes against the trunk. When we need an alpha (pre-complete) release, we just tag the trunk. Once we hit "code complete" for a given release, we create a code freeze branch, where we do all our version changes. The beta, RC and GA releases are tagged from that branch. If we need to patch a GA release, the patch is done against the branch and merged to the trunk. That way, we don't have to worry about newer code leaking into the tested and approved GA if we need to patch something specific. It also allows us to start working on the next version of the software as soon as the code is frozen.
Also, if there's a "side project" that is out-of-band for the trunk, you can create a branch for that and merge it when you're ready.
Some teams like to create a branch for every bug, and some work directly on the trunk (like mine). If your team does the bug-per-branch, I'd never check out the whole project. Among other things, I'd see a whole lot of code I wouldn't care about.
Also, just a point about the repository management as mentioned by
@humble_coder- most Subversion tools are pretty easy to use when it comes to branch/tag management. For example, TortoiseSVN has a repository browser that allows you to copy things around (creating branches and tags) pretty easily, and even the svn command-line tool can be used to do the same thing as an atomic operation (we actually have a script that creates either the alpha tags, the code freeze branch, or the post-freeze release tags).Hope this helps!
通常一个 Subversion 存储库有 3 个主要目录：
Trunk 用于存放最新的代码分支。
通常创建分支是为了开发您在主干中尚不需要的特定功能。
标签就像主干的保存点。
如果您在项目的根目录进行签出，您将获得所有分支、所有标签和主干。这可能会产生大量数据。
例如，如果每个代码版本都被标记，您将获得所有过去版本的源代码！
我希望这会对您有所帮助
杰罗姆·瓦格纳
usually a subversion repository has 3 main directories :
Trunk is for the most up to date branch of the code.
Branches are usually created in order to develop a specific feature that you do not yet want in the trunk.
Tags are like save-points of the trunk.
If you do a checkout at the root of the project, you will get all the branches, all the tags and the trunk. This can lead to a huge amount of data.
For example, if each code release is tagged, you will get the source code from all your past releases !
I hope this will help you
Jerome Wagner
这取决于您如何布局存储库，但通常，您将具有以下结构：
在
tags和branches内，您可能有该项目的多个副本（再次取决于您如何使用存储库）。如果您的存储库以这种方式布局，并且您签出
/，您最终将获得代码的多个副本（标签和分支），您可能不应该触摸它们（标签，例如实例）。如果您改为签出
/trunk，则只会签出您当前正在使用的版本，这也是您通常想要的版本。It depends on how do you lay out your repository, but usually, you'll have this structure:
Inside both
tagsandbranches, you may have several copies of the project (depending again on how do you use the repository).If your repository is laid out this way, and you checkout
/, you will end up with several copies of the code (tags and branches), that you may not be supposed to be touching (tags, for instance).If you checkout
/trunkinstead, you'll only check out the version you are currently working on, which is what you usually want.我永远不会检查整个项目。通常，我一次只对一个分支感兴趣，也许两个，偶尔三个。我总是检查并更新后备箱。如果我需要检查已发布标签的操作（也许是为了错误调查），我会检查、调查并删除。存储在
branch下的分支通常具有更短的注意力跨度，也就是说，它们在短时间内被狂热地创建和使用，然后再也没有被触及。I would never checkout the whole project. Typically, I am only interested in one branch at a time, maybe two, occasionally three. I always have trunk checked out and updated. If I need to check the operation of a released tag (maybe for bug investigation) I check it out, investigate and delete. Branches stored under
branchestypically have a much shorter attention span, that is, they are created and used feverishly for a short period and then never touched again.