创建 Subversion 存储库的最佳实践？
我们的团队（5-10 名开发人员）计划为我们的 .NET (Visual Studio) 项目/解决方案（VisualSVN Server、TortoiseSVN / VisualSVN）采用 Subversion。
组织新存储库树的最佳方式是什么？ 可以使用一个大存储库还是为每个解决方案/产品线等创建不同的存储库更好？
我们的项目可以这样分类（示例）：
- 主要产品线
- 主要网络应用程序
- 图书馆1
- 图书馆2
- ...
- Windows 客户端
- 另一个 Windows 客户端
- Windows 服务
- 主要网络应用程序
- 工具
- 工具A
- 工具B
- 产品线 2
- 软件 1
- 软件 2
- 产品线 3
- 应用 1
- 应用程序 2
Our team (5-10 developers) plans to adopt Subversion for our .NET (Visual Studio) projects/solutions (VisualSVN Server, TortoiseSVN / VisualSVN).
What is the best way to organize a new repository tree? Is it okay to use one big repository or is it better to create different repositories for every solution / product line etc.?
Our projects can be categorized this way (example):
- Main Product Line
- Main Web App
- Library 1
- Library 2
- ...
- Windows Client
- Another Windows Client
- Windows Service
- Main Web App
- Tools
- Tool A
- Tool B
- Product Line 2
- Software 1
- Software 2
- Product Line 3
- App 1
- App 2
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我的灵感来源：
My source of inspiration:
一般来说，在任何需要不同访问权限的情况下，您都希望使用单独的存储库（即某些开发人员应该具有对一个项目的提交访问权限，但不能对另一个项目进行提交访问，或者一个项目具有公共只读匿名接口，但另一个项目没有） t）。
如果您不需要这一级别的访问控制，您希望所有内容都在一个存储库中，特别是如果您需要能够在项目之间复制或移动文件（即项目可能共享代码）。
将您的主干/标签/分支拆分在与您可能作为单个包发布的代码块相对应的任何级别（即考虑您要标记的位置）。 这对于一开始就正确并不重要，因为这些文件夹在内部与任何其他文件夹没有什么不同，所以您可以稍后移动内容，当然，最好不要出现这个问题。
Generally, you want to use a separate repository in any case where you are expecting different access permissions (i.e. some developers should have commit access to one project, but not another, or one project has a public read-only anonymous interface but another doesn't).
You want everything in one repository if you don't need that level of access control, especially if you need to be able to copy or move files between projects (i.e. projects might share code).
Put your trunk/tags/branch split at whatever level corresponds to a chunk of code you might release as a single package (i.e. think of where you would tag). This isn't critical to get right at first, since these no different internally from any other folder, so you can just move things around later, though of course it's neater not to have that problem.
存储库。
存储库。
转发。
最好不要把你的全部
鸡蛋放在一个篮子里。
您的存储库结构对于您的业务及其产品来说将有些独特。 我们将我们的保存在一个存储库中。 我们的结构有点像这样。
repository.
repository.
repostitory.
preferrable not to put all of your
eggs in one basket.
Your repository structure will be somewhat unique to your business, and it's products. We keep ours in one repository. Our structure somewhat like this.
我们使用一个大的存储库，并将所有内容都存储在子文件夹（/project1、/project2 等）中，这似乎工作正常。
Apache 项目有一个巨大的 svn 存储库，而且似乎对他们来说还不错！ :)
在组织方面，你给出的结构看起来很合理。 我认为任何事情都会发生，只要它是合理的（即将每个工具与每个项目混合可能是一个坏主意等）。 因此，选择适合您的东西（工具/项目/等）。 Subversion 对在存储库中移动内容也提供了很好的支持，因此您可以随时在必要时进行更改。
We use one big repository, and just have everything structured in subfolders (/project1, /project2 etc) and that seems to work fine.
The Apache project has a huge svn repository and it seems to do OK for them! :)
In terms of organisation, the structure you gave looks quite reasonable. I think anything goes, pretty much, so long as it's rational (i.e. mixing up every single tool with every single project is probably a bad idea etc). So pick something which works for you (tools/, projects/ etc). Subversion has pretty good support for moving things around in the repository, too, so you can always change if necessary.
我们有一个像这样结构的存储库。 任何由多人处理和/或正在积极开发的内容都在主文件夹下使用 trunk/tags/branch/ 进行设置。
我们可能会将这些 trunk-tags-branch 文件夹集放在您列出的每个子文件夹下，除了一两个未积极开发的库。
We have a single repo that's structured like that. Anything that is worked on by more than a few people and/or in active development is set up with trunk/ tags/ branch/ under the main folder.
We would probably put those the trunk-tags-branch folderset under every subfolder you listed, except maybe a library or two that aren't in active development.
我们为每个项目都有单独的存储库； 但主要原因是出于访问原因，此外，如果客户想要其源代码的副本，我们可以将其连同历史记录一起提供给他们，而无需太多麻烦。 如果您查看conf 中的配置文件，那么拥有一个适用于所有项目的通用配置文件并不难。 我们这样做：
authz:
然后当然是 passwd:
We have separate repos for each project; but the main reason is for access reasons plus if the customer wants a copy of their source we can give it to them with history without too much fuss. If you look at the config files in conf it's not that hard to have a universal config file that will work for all of your projects. We do it like this:
authz:
and then of course passwd:
尝试将定期访问的材料（代码、脚本）与“一次写入并提交备份”的内容分开。 仅仅为了更改几行代码就必须检查/更新数千个 jpeg，很快就会变得乏味。
Try to keep regularly accessed material (code, scripts) separate from the 'write-once and commit to backup' stuff. Having to checkout/update thousands of jpegs just to change a few lines of code gets dull very quickly.
我正在使用一个存储库和许多项目，如下所示：
我唯一关心的是备份和恢复。 SVN 备份是在存储库级别完成的，因此恢复将恢复所有项目，而不是仅恢复一个项目。
吉荣
I am using one repository and many projects as below:
My only concern is the backup and restore. The SVN backup is done at the repository level, so the restore will restore all projects instead of just one.
Jirong