我的团队即将发布，我们希望在subversion中标记该版本。发行版（v.1）由几个应用程序组成，它们都引用共享库。 我读到组织主干/分支/标签最常用的方法是按项目进行。
问题＃1：那么要使用这种结构进行发布，我是否必须分别标记每个项目？ 我在想的是我可以创建几个级别的主干/分支/标签，一个在根中，一个用于每个项目。这样我就可以从根干线为我的所有代码创建一个标记。
would look something like this:
/rep
/trunk
/office
/project1
/trunk
/branches
/tags
/project2
/trunk
/branches
/tags
/shared
/shared_project
/trunk
/branches
/tags
/tags
/branches
问题2：如果我对Q＃1的解决方案是个坏主意而且我必须为自己标记每个项目，那么，如果我们稍后在v.1中发现了一个错误并且需要创建一个修补程序。那么我是否还必须手动将每个项目切换到v.1标记并将它们分支到开发分支？
修改
感谢您的回答。我已经决定，我会说服我的团队转移到Mercurial，看起来像是我们想要工作的合适的VCS。我也看了一下git但是看起来更顺利。
答案 0 :(得分：2)
由于所有项目都是独立版本化的，因此单独标记每个项目将为您提供最大的灵活性。
如果您担心标记所有这些项目所需的工作，可以使用svn命令行客户端轻松完成此操作
svn cp <branch> <tag> -m"tagging release v.1"
你问题中展示的嵌套将最终导致无法维护的混乱。
假设您的存储库位于http://mysvn/，具有以下布局：
/rep
/trunk
/project1
/project2
/shared_project
/tags
/branches
如果要从trunk标记项目，可以从命令行运行以下命令。
svn cp "http://mysvn/trunk/project1" "http://mysvn/tags/project1 v.1" -m"tagging release v.1"
svn cp "http://mysvn/trunk/project2" "http://mysvn/tags/project2 v.1" -m"tagging release v.1"
svn cp "http://mysvn/trunk/shared_project" "http://mysvn/tags/shared_project v.1" -m"tagging release v.1"
结果是以下存储库布局
/rep
/trunk
/project1
/project2
/shared_project
/tags
/project1 v.1
/project2 v.1
/shared_project v.1
/branches
另一种方法假设您的存储库具有以下布局：
/rep
/project1
/trunk
/tags
/branches
/project2
/trunk
/tags
/branches
/shared_project
/trunk
/tags
/branches
在这种情况下，您将使用以下命令进行标记：
svn cp "http://mysvn/project1/trunk/" "http://mysvn/project1/tags/v.1" -m"tagging release v.1"
svn cp "http://mysvn/project2/trunk/" "http://mysvn/project2/tags/v.1" -m"tagging release v.1"
svn cp "http://mysvn/shared_project/trunk/" "http://mysvn/shared_project/tags/v.1" -m"tagging release v.1"
这将使您的存储库处于以下状态：
/rep
/project1
/trunk
/tags
/v.1
/branches
/project2
/trunk
/tags
/v.1
/branches
/shared_project
/trunk
/tags
/v.1
/branches
就个人而言，我更喜欢第一种方法，因为它将标签下的文件夹保持在与主干相同的级别上，并且最终不会有一堆名为“v.1”的文件夹。最后，这是一个偏好问题。
答案 1 :(得分：1)
这个结构对我来说似乎不对：
/rep
/trunk
/office
/project1
/trunk
为什么trunk低于/rep？它应该是：
/rep
/office
/project1
/trunk
接下来，您需要创建一个包含特定时间所有版本的标记。我建议创建一个包含/rep/all/tag/1.0/office/project1
使用svn copy或使用svn:external填充ueberproject。
前者像版本化文件系统一样使用SVN：您可以创建要处理的文件的副本。
后者创建了您需要的点点滴滴的轻量级链接。在SVN中，两个操作的成本大致相同（svn副本也在内部创建了几个链接;它实际上并不复制任何东西！）
如果你在v1中发现了一个错误，你应该将项目导出到像Mercurial或Git这样的DCVS中，在那里创建分支，修复bug。
与所有集中式VCS一样，SVN并不擅长分支和合并。当然，这个操作并不像CVS那样耗费时间，但从逻辑上讲，这是一团糟。
请参阅http://hginit.com/以获取更长的解释，说明为什么您不想在Subversion中以分支开头。
如果您仍想尝试，请阅读并理解：http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
答案 2 :(得分：0)
首先让我说这里没有正确的答案（虽然有很多错误的答案）。
如果您将每个可部署项目放在一个单独的分支中，您最终可能会遇到维护问题，并试图维护一个与哪些内容兼容的列表。我唯一一次提倡这样做是因为你所谈论的是完全独立的产品，这些产品肯定是独立部署的，例如：一个软件创建者，可以创建多个不同的应用程序，单独销售和独立版本化。
如果这是内部的，那么管理一个存储库并将其作为整体分支/标记要容易得多。如果项目尚未更改，则您无需部署它 - 您要做的就是确保实时系统由存储库中的分支或标记表示。
对于共享库，您应该使用SVN-externals - 将公共库存储在单独的程序集中，并使用externals将它们包含在构建中。
/rep
/trunk
/office
/project1
/project2
/project3
/Release 1.0
/office
/project1
/project2
/project3
/Release 1.1
/office
/project1
/project2
/project3
/Release 2.0
/office
/project1
/project2
/project3
/tags
/Release 1.0
/office
/project1
/project2
/project3
/Release 1.1
/office
/project1
/project2
/project3
/Release 2.0
/office
/project1
/project2
/project3
请注意，我有标签和分支 - 标签是指向与部署对应的单个修订的指针。分支从相应标记的位置开始，但是在您需要热修复生产系统的情况下，它们是您修复代码的地方。
所以回答2）是的，如果你在2周前部署的2.0版本中有一个bug，你需要切换到在R2.0分支中工作，修复bug，然后将修复程序合并到trunk中所以它也包含在未来的版本中。
我个人在我的本地磁盘上维护了几个分支，而不是使用我感到困惑的交换机。
答案 3 :(得分：0)
这是我对你的问题的看法。
Q1：您可以像所做的那样为所有项目使用一个存储库。您可以在生成服务器上部署之前制作每个项目的snaptshots（标签），例如在trunk / office / project1 / tags中标记project1版本
然而对我来说更正确的结构是：
/rep
/trunk
/project1
/project2
/shared
/tags/
/project1
/project2
/shared
/branches
/project1
/project2
/shared
当您检查行李箱时，您将进入项目的所有行李箱版本。
Q2。如果您在标记v1中发现错误，则需要从分支中的该标记切换或修复主干中的错误并在生产服务器上进行新部署以及新标记 - 这取决于您的开发周期。