颠覆结构问题
刚刚从 Visual Studio 转向颠覆。 我已经喜欢它了！ 有人可以简要解释一下
- 存储库
- 分支
- 标签
- 主干
我需要为每个项目创建一个新的存储库吗？ 还是新行李箱？
谢谢
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
刚刚从 Visual Studio 转向颠覆。 我已经喜欢它了！ 有人可以简要解释一下
我需要为每个项目创建一个新的存储库吗？ 还是新行李箱？
谢谢
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
您不需要单独的存储库，但如果您愿意的话也可以。 我建议您在 http://svnbook.red-bean.com/ 上阅读该书。 获取 pdf 版本或其他版本。 它不需要太长的时间，并且很好地解释了一些事情。 我读了它，发现我很高兴我做到了。
You don't need a separate repository, but you can if you want. I recommend reading the book at http://svnbook.red-bean.com/. Grab the pdf version or whatever. It doesn't take too long, and it explains some things pretty well. I read it, and found that I'm glad I did.
请记住，Subversion 只是一个支持版本控制的奇特文件系统。 将存储库视为“驱动器根”，如“C:/”。
每个项目都有一个主干、标签和分支目录。 您所有的日常工作都在后备箱中进行。 实验代码在分支中完成，然后稍后合并回主干。 标签是在您发布软件时使用的。 这些不可被编辑。 当您发布软件时，您可以根据主干中当前的内容创建一个具有唯一名称的标签。
我不能说每个项目是否需要一个单独的存储库，这都有优点和缺点。 此博客文章详细介绍了这些内容：
Remember that subversion is just a fancy filesystem that supports versioning. Think of a repository as a "drive root" like "C:/".
Each project gets a trunk, tags and branches directory. All of your day to day work happens in the trunk. Experimental code is done in a branch and then merged back into the trunk at a later date. Tags are for when you release the software. These are not to be edited. When you release the software, you create a tag with a unique name based on what is currently in the trunk.
I can't say whether or not you need a separate repository for each project, there are pros and cons. This blog posting details them:
我同意，请阅读 svnbook。 这是一个很好的资源。
Kevin 很好地介绍了单个/多个存储库的权衡。 当我们开始使用 svn 时，我们为所有开发项目使用一个存储库。 它运行良好并且具有提到的所有优点。 然而，随着存储库变得越来越大，由于转储文件的大小以及备份过程中产生的问题，管理变得更加困难。 这也成为一个问题，即项目无法轻松地从存储库中归档 - 这当然是可能的，但它需要从存储库中转储和提取项目。 它们不是无法解决的问题，但需要牢记在心。
分支、标签和主干只是存储库中包含的文件的副本。 它允许您在任何您认为合适的时间（通常在发布或功能分支）分离并选中您的文件。
关于分支、标签和主干需要记住的重要一点是它们只是 svn 中的约定。 这三个位置之间没有功能差异，它们只是一种可接受的使用模型，如果您有充分的理由，可以对它们进行更改或以不同的方式进行组织。 我不建议您以不同的方式组织，但您会发现 svn 非常灵活，因为除了惯例之外，实际上没有强制的组织结构。
根据您决定在存储库中拥有多少项目，您可以进行不同的组织。
您可以让子目录及其下的项目：
或者您可以让项目包含子目录：
svnbook 中涵盖了一些权衡。 如果每个存储库只有一个项目，通常使用第一种方法；如果存储库中有多个项目，则通常使用第二种方法。
好处是您可以开始使用 svn，然后弄清楚您喜欢什么。 您应该有某种组织，但是，使用便宜的副本，您始终可以根据情况或工作流程的变化重新排列文件夹。
I agree, read the svnbook. It's a great resource.
Kevin covered the single/multiple repository trade-offs pretty well. When we started with svn, we used one repository for all of our development projects. It worked well and had all the advantages mentioned. However, as the repository got bigger it got more difficult to administer because of the size of the dump file and resulting issues during backup. It also became an issue that projects couldn't easily be archived out of the repository - it's certainly possible but it requires dumping and pulling out projects from the repository. They aren't issues you can't get around but it's something to keep in mind.
Branches, tags and the trunk are just copies of your files contained in the repository. It allows you to segregate and check-mark your files at whatever time you feel appropriate (usually at a release or a feature branch).
An important thing to keep in mind about branches, tags and trunk is that they just conventions in svn. There is no functional difference between the three locations, they are just an accepted usage model and they can be changed or organized differently if you have a good reason. I'm not recommending that you organize differently but you'll find that svn is very flexible because there isn't really a forced organizational structure other than convention.
Depending on how many projects you decide to have in your repository, you may organize differently.
You can have the subdirectories with projects under it:
or you can have projects contain the subdirectories:
There are trade-offs that are covered in the svnbook. The first method is usually used if you only have one project per repository and the second if there is more than one project in your repository.
The nice thing is that you can just start using svn and then figure out what you prefer. You should have some sort of organization but, with cheap copies, you can always re-arrange the folders as your situation or workflow changes.
与 CVS 或 Git 等其他版本控制系统相比，使用 SVN 需要记住的一件重要事情是，SVN 实际上没有概念、分支或标记。 就 SVN 而言，它只是一堆文件夹和文件。 因此，虽然您会看到很多人使用分支/标签/主干设置，但这不是必需的，如果您选择的话，您可以偏离此设置。
一般来说，“主干”是你保持积极发展的地方。 所以这是你进行所有提交的地方。 您是否签出主干或使用标签/分支完全取决于您。
正如我所使用的那样，分支通常用于当您需要对应用程序进行较大更改但不希望它们位于主干中时，因为您希望能够继续针对主干进行开发而不部署其他更改。 在这种情况下，您可能会遇到类似的情况，
在这种情况下，您可以分别在 trunk 和 version_two 中进行开发，并且假设您的实时站点是 trunk 的签出，您无需担心“意外”破坏您的实时站点与其他站点变化。 当这些更改完成并准备好后，您只需将它们合并回主干即可。
标签的使用方式与分支类似，因为您不必签出主干并仅使用“svn up”来更新存储库，而是使用多个标签，每个标签代表一个版本。 因此，您的存储库可能看起来像这样，
在这种情况下，总体思路是，当您准备好进行部署时，您可以执行“
将主干复制到标签”（在这种情况下，下一个可能是 1.1.1、1.2.0） 、2.0.0 等）。 如何命名标签完全取决于您，并且同样取决于您的项目和要求。 使用此路由，您将不得不执行 svn switch，而不是执行常规的“svn up”。 因此，您必须部署
交换机，它会自动对相应的文件进行更新、添加和删除。
当涉及到多个项目的一个存储库或每个项目的单独存储库时，我主张每个项目一个存储库。 它提供了轻松管理对其访问的额外好处。 但最重要的是，这意味着每个项目都有单独的提交历史记录和单独的日志。 这米
An important thing to remember with SVN, compared to other version control systems like CVS or Git, is that SVN doesn't really have a concept or branching or tagging. As far as SVN is concerned it's all just a bunch of folders and files. So while you'll see a lot of people using the branches/tags/trunk setup, this is not required and you are able to deviate from this if you so choose.
Generally speaking 'trunk' is where you keep your active development going. So this is where you do all your commits. Whether or not you checkout trunk or use tags/branches instead is entirely up to you.
Branches, as I've used them, are usually for when you need to do large changes to your application but don't want them in trunk because you want to be able to continue developing against trunk without deploying your other changes. In this case you may have something like
In this case you can develop in both trunk and version_two separately and, assuming your live site is a checkout of trunk, you don't need to worry about 'accidentally' breaking your live site with your other changes. And when those changes are done and ready you just merge them back into trunk whenever you want.
Tags can be used similarly to branches, in that instead of checking out trunk and just using 'svn up' to update your repository you instead of several tags, each representing one release. So your repo may look something like
In this case the general idea is that when you're ready to do a deploy you do an
To copy trunk over to a tag (in this case the next one could be 1.1.1, 1.2.0, 2.0.0, etc). How you name your tags it entirely up to you though and, again, depends on your project and requirements. With this route instead of doing a regular 'svn up' you would have to do an svn switch. So you have to deploy with
The switch will automatically do updates, adds and deletes on the appropriate files.
When it comes to one repo for many projects or separate repos for each one I am an advocate of one repo per project. It provides the additional benefits of easily managing access to it. But most importantly it means that each project has a separate commit history and separate logs. This m
阅读您的标签，我发现您开始使用 VisualSVN 而不是旧的 VSS 系统。 （你的问题说你停止使用 Visual Studio.. 这使得 VisualSVN 成为一个奇怪的选择）。
SourceSafe 和 VSS 之间的主要区别之一是您可以选择不同的工具来访问同一存储库（并且您可以随时切换，因为它们都共享相同的工作副本）。
例如：
Reading your tags I see you started using VisualSVN instead of your old VSS system. (Your question says you stopped using Visual Studio.. which makes VisualSVN a strange choice).
One of the major differences between SourceSafe and VSS is that you can choose different tools to access the same repository (and you can switch every time you like as they all share the same workingcopy).
E.g.: