4

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

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

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

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

我看到的好处是:

  • 更新和签入很容易,因为我有一个所有项目的公共根目录(主干)。一个简单svn updatesvn 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 updatesvn 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 回答