SVN项目结构 [英] SVN project structure

问题描述

我们正在从 VSS 迁移到 SVN，并且正在讨论项目结构.我们正在辩论下面显示的两个提案.

没有.1 对于开发支持似乎更简单，因为项目发布版本与标签，开发人员只需对该标签执行更新即可立即开始工作.

没有.2 确保所有项目和依赖项都可以独立开发，但构建一个特定的发布版本意味着知道项目的标签和所有这是依赖关系.

两者之间是否有明显的比较优势?这两个结构中有什么问题吗?或者有更好的结构吗?

<前>1.发展+ 后备箱项目1项目2依赖1依赖2依赖3+ 分支机构+ 标签2.项目1+ 后备箱+ 分支机构+ 标签项目2+ 后备箱+ 分支机构+ 标签依赖1+ 后备箱+ 分支机构+ 标签依赖2+ 后备箱+ 分支机构+ 标签依赖3+ 后备箱+ 分支机构+ 标签

解决方案

总的来说，我建议让项目尽可能保持独立(您的第二个选择).这通常会促进重用.(如果我只想要 Dependency2，我不需要带一个完整的其他项目来实现它.)

但是，您必须对依赖项真正要执行的操作保持清醒.例如，如果 Dependency2 only 将成为 Project1 的依赖项，那么它可能只存在于 Project1 的源结构中.(注意:我的意思不是为依赖项设置单独的分支和标签 - 我的意思是将它放在不同的包中，或 Project1 中的另一个子项目中.)

如果您想让项目成为组织内可重用的库，请将其作为一个单独的项目完全独立，以免引入不必要的相互依赖.而且，我鼓励您的开发团队不要检查依赖项并与之一起工作.相反，构建依赖项并将它们用作二进制库.这样，无论谁签出一个项目来处理它，都将始终拥有应用程序所需的最新库依赖项.如果需要更新，那么您可以担心检查依赖项并构建它.(或者，更好的是，有一个位置，项目团队可以将最新的库作为二进制文件发布.)

项目和依赖项的版本更新如果您采用#2 路线，并且拥有单独的项目和依赖项，那么您的版本控制实际上变得非常简单.以下是其工作原理的概述.

1. 团队 A 正在处理 Project1.
2. 团队 B 正在研究 Project1 所依赖的 Dependency1.
3. 每当 B 团队完成他们的工作时，他们就会构建一个 Dependency1 版本(一个二进制文件 - 可能是一个 DLL，或者一个库，或者类似的东西).他们也可以在这个时候标记他们的项目.二进制名称可能是:Dependency1-v1.0.0
4. 团队 A 采用了 Dependency1-v1.0.0 的二进制版本，并将其包含在他们的项目中.(通常，二进制文件保存在项目中的/lib 文件夹或类似文件夹中.)
5. 每当 A 团队完成他们的工作时，他们就可以发布他们的项目并标记他们的项目.

请注意，A 团队在任何时候都不会检出来自 Dependency1 的源代码并将其带入他们的项目中.这允许两个项目的开发保持独立，以便开发团队之间有自主权.团队 A 可以根据需要使用二进制文件的时间长短.如果他们想要更新版本，他们可以从 B 团队获取最新版本.

这个过程与您使用外部来源的库时所做的并没有太大区别.您无法控制他们如何对其库进行版本控制，因此您只需获取项目所需的内容并在您认为必要时进行更新.您将二进制文件保存在您自己的项目结构中，以便您始终可以依赖它.

We are moving to SVN from VSS and are debating the project structure. We are debating two proposals displayed below.

No. 1 seems simpler for development support since a Project release version is tied to a tag and the developer would only need to perform an update on that tag to immediately get to work.

No. 2 insures that all Projects and Dependencies can be developed independently but building a particular release version means knowing the tags of the Project and all it's Dependencies.

Are there obvious comparative benefits between the two? Any gotchas in the two structures? or are there better structures out there?

1.
Development  
  + trunk  
    Project1  
    Project2  
    Dependency1  
    Dependency2  
    Dependency3  
  + branches  
  + tags  

2.
Project1  
  + trunk  
  + branches  
  + tags  
Project2  
  + trunk  
  + branches  
  + tags  
Dependency1  
  + trunk  
  + branches  
  + tags  
Dependency2  
  + trunk  
  + branches  
  + tags  
Dependency3  
  + trunk  
  + branches  
  + tags  

解决方案

In general, I recommend having projects remain separate as much as makes sense (your second option). This will generally promote reuse. (If I only want Dependency2, I don't need to bring an entire other project in order to get to it.)

However, you have to be smart about what your dependencies are really going to be doing. For example, if Dependency2 is only going to be a dependency for Project1, then it should probably just exist within Project1's source structure. (Note: I do not mean have separate branches and tags for the Dependency - I mean have it be in a different package, or another subproject within Project1.)

If you want to make a project a reusable library within your organization, then have it as a separate project completely so you don't introduce unnecessary co-dependencies. And, I would encourage your development team not to check out a dependency and work alongside that. Instead, build the dependencies and use them as a binary library. This way, whoever checks out a Project to work on it will always have the latest library dependency that they need for the application. If an update is needed, then you can worry about checking out the Dependency and building it. (Or, even better, have a location where project teams can release the latest libraries as binary files.)

Update on Versioning of Project and Dependencies If you go with the #2 route, and have separate Project and Dependencies, your versioning actually becomes very simple. Here is an outline of how it might work.

1. Team A is working on Project1.
2. Team B is working on Dependency1 which Project1 depends on.
3. Whenever Team B finishing their work, they build a release of Dependency1 (a binary - perhaps a DLL, or a library, or something along those lines). They can also tag their project at this time. The binary name may be: Dependency1-v1.0.0
4. Team A takes the binary release of Dependency1-v1.0.0 and includes it in their project. (Typically, binaries are kept in a /lib folder or something like that within the project.)
5. Whenever Team A finishes their work, they can release their project and tag their project as well.

Note that, at no point, does Team A check out the source code from Dependency1 and bring it into their project. This allows development of the two projects to remain separate so that there is autonomy between the development teams. Team A can use the binary for as long or as short as they like. If they want an updated version, they go get the latest release from Team B.

This process is not really much different from what you would do if you were using a library from an outside source. You have no control over how they version their library, so you just grab what you need for your project and update when you feel is necessary. You keep the binary within your own project structure so that you can always rely on it.

这篇关于SVN项目结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！