Subversion，标记版本，共享库

如何解决Subversion，标记版本，共享库

| 我的团队即将发布版本，我们希望在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，但hq看起来更流畅。     

解决方法

由于所有项目都是独立版本的，因此单独标记每个项目将为您提供最大的灵活性。 如果您担心标记所有这些项目所需的工作，则可以使用svn命令行客户端轻松完成此操作

svn cp <branch> <tag> -m\"tagging release v.1\"

像您在问题中显示的那样嵌套会导致无法维护的混乱。 一个例子 假设您的存储库位于ѭ2上，布局如下：

/rep
  /trunk
        /project1
        /project2
        /shared_project
  /tags
  /branches

当您要从中继标记项目时，可以从命令行运行以下命令。

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”的文件夹。最后，这是一个偏好问题。     ,这种结构对我来说似乎是错误的：

/rep
    /trunk
        /office
            /project1
                /trunk

为什么在11ѭ以下有10ѭ？它应该是：

/rep
    /office
        /project1
            /trunk

接下来，您需要创建一个标签，其中包含特定时间的所有版本。我建议创建一个包含其他项目（例如

/rep/all/tag/1.0/office/project1

）的ueberproject 用

svn copy

或

svn:external

填充ueberproject。 前者使用SVN就像版本文件系统一样：创建要处理的文件的副本。 后者创建指向您所需的点点滴滴的轻量级链接。在SVN中，这两种操作的成本大致相同（svn复制还在内部创建了几个链接；实际上并没有复制任何内容！） 修正错误 如果在v1中发现错误，则应将项目导出到Mercurial或Git之类的DCVS中，在其中创建分支并修复该错误。 像所有集中式VCS一样，SVN并不是真正擅长分支和合并。当然，该操作并不像CVS那样花费时间，但是从逻辑上讲，这是一团糟。 请参阅http://hginit.com/了解有关为什么不想在Subversion中以分支开头的详细说明。 如果您仍然想尝试，请阅读并理解以下内容：http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html     ,首先让我说这里没有正确的答案（尽管有很多错误的答案）。 如果将每个可部署项目放在单独的分支中，则可能会导致维护麻烦，试图维护与哪些项目兼容的列表。我唯一提倡这样做的是，如果您谈论的是完全独立部署的非常独立的产品，例如一个软件创建者，可以创建多个不同的应用程序，分别出售和独立版本控制。 如果这是内部的，则管理一个存储库并将其整体进行分支/标记要容易得多。如果没有更改项目，则无需部署它-您要做的就是确保实时系统由存储库中的分支或标记表示。 对于共享库，您应该使用SVN外部库-将公共库存储在单独的程序集中，并使用外部库将它们包括在构建中。

 /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周前部署了Release 2.0中的一个错误，则需要切换到在R2.0分支中工作，修复该错误，然后将其合并回主干，以便它也包括在将来的版本中。 就我个人而言，我在本地磁盘上维护了几个分支，而不是使用令人困惑的开关。     ,这是我对您的问题的看法。 问题1：您可以像以前一样对所有项目使用一个存储库。您可以在将每个项目部署到生产服务器上之前为其制作快照（标签）。在trunk / office / project1 / tags中标记project1版本 但是对我来说，这种结构更正确：

/rep
   /trunk
     /project1
     /project2
     /shared
   /tags/
     /project1
     /project2
     /shared
   /branches
     /project1
     /project2
     /shared

这样，当您结帐干线时，您将获得一次放置项目所有干线版本的操作。 Q2。如果您在标签v1中发现错误，则需要从分支中的该标签切换或修复主干中的错误，然后在生产服务器上进行新部署以及新标签-这取决于您的开发周期。