颠覆一次
可能的重复：
“分支”、“标签”和“主干”的真正含义是什么？
我是颠覆新手，所以请耐心等待。我知道存储库的标准目录结构如下：
/branches/
/tags/
/trunk/
我不确定每个目录的用途。有人可以：
- 描述每个目录的用途
- 为单用户环境中的项目管理提供示例目录结构
- 为多用户环境中的项目管理提供示例目录结构环境
- 为父项目提供示例目录结构，其中将包含多个附加组件，每个附加组件都是自己的较小项目
对于问题的崩溃列表，我们深表歉意。对于好的答案，我将给予加分。
谢谢您的宝贵时间！
Possible Duplicate:
What do “branch”, “tag” and “trunk” really mean?
I am brand new to subversion, so please bear with me. I know that the standard directory structure for a repository are as follows:
/branches/
/tags/
/trunk/
I'm not sure what each of these directories are for. Could someone:
- describe the purpose of each directory
- provide a sample directory structure for project management in a single-user environment
- provide a sample directory structure for project management in a multi-user environment
- provide sample directory structure(s) for a parent project which will contain multiple add-ons, each being their own smaller project
Sorry for the crash list of questions. I will award extra points for good answers.
Thank you for your time!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你可以看看这里：“branch”、“tag”和“ trunk”在 Subversion 存储库中意味着什么？
一个额外的细节是所有文件夹都是相同的，这只是具有这种结构的约定，它们本身没有特殊含义。该结构在单用户或多用户环境中应该是相同的，并且通常是问题中的结构。
在多用户环境中，有时我们有
/privatebranches，这意味着它是某种尖峰，不适合一般用途。此外，这些可能是非标准的，如主干中特定文件夹的分支等。对于多个附加类型项目：
同样在这种情况下，您可以查看使用 svn externals 来管理项目。因此它们仍将具有上述结构，但您可以使附加组件看起来像是包含在 Project1 中
you can look here : What do "branch", "tag" and "trunk" mean in Subversion repositories?
One additional detail is that all the folders are just same, it is just a convention to have this structure and they do not have special meaning per se. The structure should be the same in single-user or multi-user environment and it is the one in the question generally.
In multi-user environment, sometimes we have
/privatebranchesmeaning that it is some sort of spike and is not for general use. Also these may be non standard as in branch of a particular folder within trunk etc.For multiple add-ons type project:
Also in that case you can look at using svn externals to manages the projects. So they will still have the above structure, but you can make it seem like the add-ons are contained within Project1