从CVS(NT)迁移到Subversion :(虚拟)模块等效于什么? [英] Migrating from CVS(NT) to Subversion: What's the equivalent of (virtual) modules?

问题描述

我们目前正在考虑从CVSNT转移到Subversion(因为我们已经在使用trac，它已经为SVN集成做好了充分的准备).由于我们已经大量使用了一些不太常见的CVS(NT)功能，因此很早就出现了几个问题.这只是他们中的第一个.

We are currently considering to move away from CVSNT, very probably to Subversion (because we are already using trac, which is well-prepared for SVN-integration). As we have been making rather extensive use of some less common CVS(NT)-features a couple of questions arose very early on. This is but the first of them.

这是场景: (对于急躁的人:我的实际问题是在这篇文章的底部，在水平尺的下方.)

我们所有的项目"都共享一些通用代码. CVS存储库中的目录层次结构看起来像这样(已简化-希望不会太大):

All of our "projects" share some common code. The directory hierarchy inside the CVS repository looks somewhat like this (simplified - hopefully not too much so):

• 库
  • Lib1
  • Lib2
  • Libs
    • Lib1
    • Lib2
    • ExtLib1
      • 文档
      • 来源
      • ExtLib1
        • Docs
        • Source
        • 文档
        • 来源

        ...例如，其中ProjectA可能依赖于Lib1，Lib2，ExtLib1和ExtLib2，而ProjectB依赖于Lib1和ExtLib1(实际上这可能是因为Lib1本身依赖于ExtLib1).我们使用CVSROOT/modules文件对此建模，如下所示:

        ...where ProjectA might for example be dependent on Lib1, Lib2, ExtLib1 and ExtLib2 and ProjectB dependent on Lib1 and ExtLib1 (actually this might be because Lib1 itself depends on ExtLib1). We modelled this by using the CVSROOT/modules file like so:

        ExtLib1Full -d Lib/ExtLib1Full    External/ExtLib1
        ExtLib1Src  -d Lib/ExtLib1/Source External/ExtLib1/Source
        ExtLib2Full -d Lib/ExtLib2Full    External/ExtLib2
        ExtLib2Src  -d Lib/ExtLib2/Source External/ExtLib2/Source
        
        Lib1        -d Lib/Lib1           Libs/Lib1
        Lib1_WDeps  -a ExtLib1Src Lib1
        Lib2        -d Lib/Lib2           Libs/Lib2
        Lib2_WDeps  -a Lib2
        
        ProjectAMain -a ProjectA
        ProjectALibs -a Lib1_WDeps Lib2_WDeps ExtLib2
        ProjectAFull -a ProjectAMain ProjectALibs
        
        ProjectALibs_OursOnly -a Lib1 Lib2
        ProjectAFull_OursOnly -a ProjectAMain ProjectALibs_OursOnly
        
        ProjectBMain -a ProjectB
        ProjectBLibs -a Lib1_WDeps
        ProjectBFull -a ProjectBMain ProjectBLibs
        
        ProjectBLibs_OursOnly -a Lib1
        ProjectBFull_OursOnly -a ProjectBMain ProjectBLibs_OursOnly
        

        对于ProjectA的构建，构建服务器现在仅需检出名为"ProjectAFull"的虚拟模块，即可获取该特定构建所需的所有相互依赖的模块-甚至可以创建编译器偏爱的目录结构(例如，外部和外部).内部库都放置在公共库"父文件夹下).同样，当我们要标记包含所有依赖项的发行版时，我们只需使用cvs rtag -rTagName ProjectAFull.在生成ChangeLog时，我们将使用cvs rlog ProjectAFull_OursOnly的输出，以防止外部库(我们使用cvs import和供应商分支对其进行维护)的提交消息污染ChangeLog.

        For a build of ProjectA the build server would now simply have to check out the virtual module named "ProjectAFull" to get all interdependent modules needed for that particular build - and even create the directory structure favoured by the compiler (i.e. external and internal libs both placed below a common "Lib" parent folder). Likewise when we want to tag a release including all dependencies we would simply use cvs rtag -rTagName ProjectAFull. When producing a ChangeLog we would use the output of cvs rlog ProjectAFull_OursOnly in order not to let the ChangeLog be polluted by commit messages from the external libraries (which we maintain using cvs import and vendor branches).

        SVN中是否有与这些虚拟模块相当的产品?我应该如何在新的SVN存储库中设置目录结构以适应此需求?每个项目和库都应该成为自己的SVN项目(即具有其自己的"trunk"，"tags"和"branches"文件夹集)还是应该仅按原样导入现有目录结构?如何定义依赖项?
        我非常希望能够继续执行只会影响相关模块的单步标记/签出/日志操作.

        Is there an equivalent of these virtual modules in SVN? How should I set up the directory structure inside the new SVN repository to accommodate for this? Should each project and library become its own SVN project (i.e. with its own set of "trunk", "tags" and "branches" folders) or should I simply import the existing directory structure as-is? How do I define the dependencies?
        I would very much prefer to continue to be able to do single-step tag/checkout/log operations that would only affect the relevant modules.

        推荐答案

        您应该查看

        You should look at SVN Externals, but note that I am not sure that I understand what you're doing with CVS, since I haven't used CVS in years.

        基本上，外部引用意味着您可以在项目下创建一个子目录，然后在其中检出另一个项目.

        Basically, an external reference means you can create a sub-directory beneath your project, and check out another project into that.

        基本上，您可以得到以下布局:

        Basically, you can get this layout:

        ProjectA      - svn://server/ProjectA
          classes      (svn://server/ProjectA/classes)
          app          (svn://server/ProjectA/app)
          externals    (svn://server/ProjectA/externals)
            Ext1      - svn://server/Ext1
              classes  (svn://server/Ext1/classes)
            Ext2      - svn://server/Ext2
        

        说明: -svn://...是我检出的url，(svn://...)是该目录的相对url，但这是母项目目录检出的一部分.

        Explanation: - svn://... is the url I checked out, (svn://...) is the relative url of that directory, but it came as part of the checkout of the mother project directory.

        请注意，外部引用作为属性添加到外部"目录中，并作为ProjectA的一部分提交到存储库中.添加完这些属性后，更新或全新签出将自动下载Ext1和Ext2作为常规签出的一部分.

        Note that the external references are added as properties to the "externals" directory, and committed into the repository as part of ProjectA. After you've added those properties, an update, or a fresh checkout, will automatically download both Ext1 and Ext2 as part of the normal checkout.

        这将在工作文件夹中提供工作文件夹，但是，您需要提交更改并分别对它们进行分支/标记. Subversion不允许您对所有这些工作副本进行修改并将它们全部提交给一个步骤.

        This will give you working folders inside working folders, however, and you'll need to commit changes and branch/tag those separately. Subversion does not allow you to do modifications to all those working copies and commit them all in one step.

        换句话说，如果要向项目添加功能，请更改ProjectA/classes中的某些文件，然后在Ext1/classes上添加一些框架支持，则必须执行两次commit，一次为Ext1.还有一个用于ProjectA.

        In other words, if in order to add a feature to the project, you change some files in ProjectA/classes, and then add some framework support on Ext1/classes, you'll have to execute two commits, one for Ext1 and one for ProjectA.

        如果您想要一个实时示例，这是我的C#类库的子目录: http://vkarlsen.serveftp.com:81/LVK/LVK_3_5/trunk/LVK.UnitTests

        If you want a live example, here's a sub-directory of my C# class library: http://vkarlsen.serveftp.com:81/LVK/LVK_3_5/trunk/LVK.UnitTests

        要检出该目录，您需要指定用户名和密码，两者均应为来宾"，且不带引号.

        To checkout that directory, you'll need to specify a username and password, both should be 'guest' without the quotes.

        我的类库单元测试项目中的外部引用包括"SigningKey"目录(检查主目录中的subversion属性)以及"libs"子目录的内容(检查libs中的subversion属性).正如您指出的那样，当您签出单元测试项目时，它拉下了库所需的所有其他内容，除了它测试的项目之外.

        External references in my class library unit test project includes both the "SigningKey" directory (check subversion properties on the main directory), as well as the contents of the "libs" sub-directory (check subversion properties on libs). As you noted, when you checked out the unit test project, it pulled down everything else it needed of libraries, well, except for the projects it tests.

        但是，如果我现在添加一个单元测试，并同时更新SQLite库文件的版本，则需要进行2次提交.一种是将新的SQLite文件放入存储库中，因为它是一个单独的项目/工作文件夹，另一种是将新的单元测试放入存储库中.

        However, if I now add a unit test, and simultaneously update the version of the SQLite library files, I need to do 2 commits. One to get the new SQLite files into the repository, because it is a separate project/working folder, and one to get the new unit test into the repository.

        这篇关于从CVS(NT)迁移到Subversion :(虚拟)模块等效于什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！