4

与“正常”的 svn 目录结构相反，我使用以下结构：

树干/
  项目1/
  项目2/
  项目3/
  ...
分支机构/
  project1-分支/
    项目1/
    项目2/
    ...
  project2-分支/
    项目1/
    项目2/
    ...
标签/
  项目1/
    V1
    V2
    ...

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

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

我看到的好处是：

  • 更新和签入很容易，因为我有一个所有项目的公共根目录（主干）。一个简单svn update或svn commit全部完成。

  • 创建标签或分支很简单，因为这只是我必须要做的主干svn copy。（分支和标签实际上包含比需要更多的项目，但是 asvn copy很便宜，如果需要，我仍然可以在分支或标签上进行稀疏检查。）

  • 将资源从一个项目转移到另一个项目很容易，因为它们都存在于同一个存储库中。

  • 当我对主干进行全面检出时，全局重构（例如更改常用类的包）很容易，因为我可以确定我不会错过任何项目。

  • 合并很容易，因为即使从一个项目到另一个项目的重构移动，我也总是可以一次合并整个分支。

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

现在我的问题是：

  • 我是否必须更改 svn 目录结构以赋予每个项目自己的三元组（主干/分支/标签）？我想答案是“是”。

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

  • 使用 Maven 的等效方法是什么？

4

2 回答 2

13

没有这样的东西，一个“正常”的 svn 目录结构。在使用 Subversion的版本控制一书的“规划您的存储库组织”一节中讨论了不同的方法（即使, ,名称也只是约定，标签和分支之间没有区别，除了您对它们的看法） ./trunk/tags/branches

  • 我是否必须更改 svn 目录结构以赋予每个项目自己的三元组（主干/分支/标签）？我想答案是“是”。

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

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

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 都将其用作父组件（简单地用groupIdand artifactId、 no引用relativePath）。对于发布，您必须先发布父 POM。

2) 这是一种便于检查项目特定分支（通常是主干）的结构。颠覆用户检查 myrepo/.links/trunk 以获取所有源的主要版本。诀窍是，该目录包含 svn:externals指向该项目的所有其他模块（parent-pom、project-A、project-B）的主干的外部链接（即带有属性）。此目录中的 pom.xml 从未发布，它仅包含三个模块的模块部分，以启用多模块构建。使用此构造，您可以轻松设置分支，例如：

myrepo
  + .links
    + branch-2.x
      + pom.xml

这个设置我用过很多次，效果很好。

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

让我一一回答每一点。

  • 由于svn externals ，更新和签入很容易。一个简单svn update或svn commit全部完成。

  • 创建标签或分支很简单，因为maven 发布插件会为您处理（标签和分支会更干净）。

  • 将资源从一个项目转移到另一个项目看起来并不复杂。

  • 全局重构（例如更改常用类的包）很容易，因为您仍然可以对主干进行完整的检出。

  • 合并可能不太容易。但是你真的经常将课程从一个项目转移到另一个项目吗？

  • 使用 Maven 的等效方法是什么？

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

于 2009-10-17T22:02:02.620 回答
1

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

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

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

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

于 2009-10-17T10:35:10.370 回答