跨多个项目的 Subversion 修订号 [英] Subversion revision number across multiple projects

问题描述

当使用 Subversion (svn) 对多个项目进行源代码控制时，我注意到我的所有项目目录中的修订号都增加了.为了说明我的 svn 布局(使用虚构的项目名称):

<前>/NinjaProg/分支/标签/树干/StealthApp/分支机构/标签/树干/SnailApp/分支机构/标签/树干

当我对 Ninja Program 的主干执行提交时，假设我知道它已更新到第 7 版.假设第二天我对 Stealth 应用程序做了一个小改动，它作为修订版返回8.

问题是这样的:在使用一台 Subversion 服务器维护多个项目时，是否普遍接受的做法是在所有项目中增加不相关项目的修订号? 或者我做错了吗?应该为每个项目创建单独的存储库?或者完全是别的什么?

我推迟标记答案，因为很明显这两种方法都有原因，即使这个问题先出现，我还是想指出一些其他问题最终都在问同样的问题:

我应该将所有项目存储在一个存储库中还是多个?

一个 SVN 存储库还是多个?

解决方案

我很惊讶没有人提到这在使用 Subversion 的版本控制中讨论过，它可以在线免费获得，这里.

我不久前阅读了这个问题，这似乎是个人选择的问题，关于这个主题有一篇很好的博客文章 这里.由于博客似乎已关闭，(此处为存档版本)，这里是马克·菲帕德 (Mark Phippard) 就此主题所说的一些内容.

<块引用>

这些是单一存储库方法的一些优点.

1. 简化管理.要部署的一组钩子.一个要备份的存储库.等
2. 分支/标签的灵活性.将代码全部放在一个存储库中，可以更轻松地创建涉及多个项目的分支或标签.
3. 轻松移动代码.也许您想从一个项目中提取一段代码并在另一个项目中使用它，或者将其转换为多个项目的库.在同一存储库中移动代码并在此过程中保留代码的历史记录很容易.

以下是单存储库方法的一些缺点和多存储库方法的优点.

1. 尺寸.处理许多较小的存储库可能比处理一个大的存储库更容易.例如，如果您停用一个项目，您只需将存储库存档到媒体，然后将其从磁盘中删除并释放存储空间.也许您出于某种原因需要转储/加载存储库，例如利用新的 Subversion 功能.如果它是一个较小的存储库，这更容易做到并且影响更小.即使您最终想要对所有存储库执行此操作，但一次执行一个的影响较小，假设没有迫切需要一次执行所有操作.
2. 全球修订号.尽管这不应该是一个问题，但有些人认为这是一个问题，并且不喜欢看到版本库中的修订号提前，并且不活跃的项目在其修订历史中存在很大差距.
3. 访问控制.虽然 Subversion 的 authz 机制允许您根据需要限制对部分存储库的访问，但在存储库级别执行此操作仍然更容易.如果您的项目只有少数人可以访问，那么使用该项目的单个代码库更容易做到这一点.
4. 行政灵活性.如果您有多个存储库，那么根据存储库/项目的需要实现不同的钩子脚本会更容易.如果您想要统一的钩子脚本，那么单个存储库可能更好，但如果每个项目都想要自己的提交电子邮件样式，那么将这些项目放在单独的存储库中会更容易

当您真正考虑时，多项目存储库中的修订号会变高，但您不会用完.请记住，您可以查看子目录的历史记录并快速查看与项目相关的所有修订号.

When using Subversion (svn) for source control with multiple projects I've noticed that the revision number increases across all of my projects' directories. To illustrate my svn layout (using fictitious project names):

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

When I perform a commit to the trunk of the Ninja Program, let's say I get that it has been updated to revision 7. The next day let's say that I make a small change to the Stealth Application and it comes back as revision 8.

The question is this: Is it common accepted practice to, when maintaining multiple projects with one Subversion server, to have unrelated projects' revision number increase across all projects? Or am I doing it wrong and should be creating individual repositories for each project? Or is it something else entirely?

EDIT: I delayed in flagging an answer because it had become clear that there are reasons for both approaches, and even though this question came first, I'd like to point to some other questions that are ultimately asking the same question:

Should I store all projects in one repository or mulitiple?

One SVN Repository or many?

解决方案

I am surprised no has mentioned that this is discussed in Version Control with Subversion, which is available free online, here.

I read up on the issue awhile back and it really seems like a matter of personal choice, there is a good blog post on the subject here. EDIT: Since the blog appears to be down, (archived version here), here is some of what Mark Phippard had to say on the subject.

These are some of the advantages of the single repository approach.

1. Simplified administration. One set of hooks to deploy. One repository to backup. etc.
2. Branch/tag flexibility. With the code all in one repository it makes it easier to create a branch or tag involving multiple projects.
3. Move code easily. Perhaps you want to take a section of code from one project and use it in another, or turn it into a library for several projects. It is easy to move the code within the same repository and retain the history of the code in the process.

Here are some of the drawbacks to the single repository approach, advantages to the multiple repository approach.

1. Size. It might be easier to deal with many smaller repositories than one large one. For example, if you retire a project you can just archive the repository to media and remove it from the disk and free up the storage. Maybe you need to dump/load a repository for some reason, such as to take advantage of a new Subversion feature. This is easier to do and with less impact if it is a smaller repository. Even if you eventually want to do it to all of your repositories, it will have less impact to do them one at a time, assuming there is not a pressing need to do them all at once.
2. Global revision number. Even though this should not be an issue, some people perceive it to be one and do not like to see the revision number advance on the repository and for inactive projects to have large gaps in their revision history.
3. Access control. While Subversion's authz mechanism allows you to restrict access as needed to parts of the repository, it is still easier to do this at the repository level. If you have a project that only a select few individuals should access, this is easier to do with a single repository for that project.
4. Administrative flexibility. If you have multiple repositories, then it is easier to implement different hook scripts based on the needs of the repository/projects. If you want uniform hook scripts, then a single repository might be better, but if each project wants its own commit email style then it is easier to have those projects in separate repositories

When you really think about, the revision numbers in a multiple project repository are going to get high, but you are not going to run out. Keep in mind that you can view a history on a sub directory and quickly see all the revision numbers that pertain to a project.

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