Question

与'普通'svn目录结构相反，我使用以下结构：

trunk/
  project1/
  project2/
  project3/
  ...
branches/
  project1-branch/
    project1/
    project2/
    ...
  project2-branch/
    project1/
    project2/
    ...
tags/
  project1/
    V1
    V2
    ...

如您所见，每个项目我没有单独的三元组（主干/分支/标签）。

对于开发我会检查包含我需要的所有项目的主干（有时是稀疏结账）（项目之间存在依赖关系，而某些项目只是库）。

我在此看到的好处是：

更新和签入很简单，因为我有一个所有项目的公共根目录（trunk）。一个简单的svn update或svn commit就可以完成所有工作。
创建标记或分支很简单，因为它只是svn copy的主干。（分支和标签实际上包含的项目比需要的多，但svn copy便宜，如果需要，我仍然可以在分支或标签上进行稀疏检查。）
将资源从一个项目移动到另一个项目很容易，因为它们都存在于同一个存储库中。
当我正在完全检查主干时，全局重构（例如更改常用类的包）很容易，因为我可以确定我不会错过任何项目。
合并很简单，因为即使从一个项目到另一个项目的重构移动，我也可以立即合并整个分支。

我打算迁移到maven并将所有项目从trunk转移到maven项目。我想从maven依赖管理和可用的插件中受益（现在我正在使用巨大的自定义ant文件）。

现在我的问题是：

我是否必须更改svn目录结构以为每个项目提供自己的三元组（主干/分支/标签）？我想答案是'是'。
如果我改变了结构，我上面提到了哪些好处（我的意思是用maven做什么会更复杂）？
使用maven的等效方法是什么？

Answer 1

没有这样的东西，一个“正常”的svn目录结构。 the section called "Planning Your Repository Organization" 书的Version Control with Subversion中讨论了不同的方法（即使/trunk，/tags，/branches名称也只是约定，标签和分支之间没有区别，除了你对它们的看法之外）。

我是否必须更改svn目录结构以为每个项目提供自己的三元组（主干/分支/标签）？我猜答案是'是'。

不，你没有必须。例如，参见Apache ServiceMix Source Tree：它是一个多模块maven项目，但模块位于一个trunk下。另一方面，XWiki的不是单一产品，而是其Source Repository页面中详述的产品和项目生态系统，它有许多主干/分支/标签。您可以浏览其存储库here以了解布局。

但是选择一种方法或另一种方法不仅仅是品味问题，它实际上取决于您的发布周期（稍后会更多地在mvn release上）。如果项目中的组件共享相同的版本（la ServiceMix），我只使用一个中继。如果他们有一个独立的发布周期（la XWiki），我会使用多个“主干/标签/分支”结构，如this thread中描述的结构：

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml 
1）项目的父POM有   一个自己的发布周期。一切   组件的POM将其用作父级   （仅使用groupId和   artifactId，没有relativePath）。对于   你必须发布一个版本   父母POM第一。

2）这是一个启用的结构   轻松检查特定分支   该项目通常是   树干。 subversion用户签出   获取头部的myrepo / .links / trunk   修订所有来源。诀窍是，   该目录包含   外部链接（即与   svn:externals财产）到   所有其他模块的中继线   项目（parent-pom，project-A，   项目-B）。这个中的pom.xml   目录永远不会发布，它   只包含一个模块部分   启用多个模块的三个模块   模块构建。有了这个结构   你可以轻松设置分支机构   e.g：
myrepo
  + .links
    + branch-2.x
      + pom.xml

我已多次使用此设置，效果非常好。

如果我改变结构，我会松开上面提到的哪些好处（我的意思是用maven做什么会更复杂）？

让我逐一回答每一点。

感谢svn externals，更新和签到很容易。一个简单的svn update或svn commit就可以完成所有工作。
创建标记或分支很简单，因为maven release plugin将为您处理此问题（标记和分支将更清晰）。
将资源从一个项目转移到另一个项目看起来并不复杂。
全局重构（例如更改常用类的包）很容易，因为您仍然可以完全检查主干。
合并可能不那么容易。但是你真的经常将课程从一个项目移到另一个项目吗？

用maven做同样的方法有哪些？

如果需要，使用maven release插件和svn externals建议的布局之一。

Answer 2

如果您只想使用Maven 进行依赖关系管理，并且您认为您的项目结构已经足够好/适合您，这里有一个有用的提示：忘记Maven。

Maven不仅仅是一个依赖管理工具，它自称“软件项目管理和理解工具”，它显然涵盖了依赖关系，但也包含了很多其他基础。由于您只想进行依赖关系管理，因此至少应该看一下Ant Ivy这样的工具，它仅用于管理依赖关系。

Ivy的真正好处在于，您可以比Maven更好地处理依赖关系管理，同时保留现有的项目结构，构建脚本以及您已经构建的任何内容。 Ivy没有强化任何项目结构或配置模式，它允许您定义从依赖项管理工具中获取的内容，然后将其添加到项目中，而不是强迫您的项目在结构上变成某些人在象牙塔中所说明的内容

为了进一步帮助您做出决定，这里是双方之间的比较：

Ivy/Maven2 comparison by Ivy developers

Maven/Ivy (plus others) comparison by Maven developers - 请记得阅读评论

从一个不寻常的svn目录结构迁移到maven？

2 个答案: