单独项目的单独存储库？答案

【问题标题】：Separate Repositories for separate projects?单独项目的单独存储库？
【发布时间】：2010-01-03 19:04:50
【问题描述】：

好的，所以基本上我的问题是关于颠覆的最佳实践。我对颠覆很陌生，所以不太了解。

所以我的问题来了。

我现在正在处理 2 个项目，并且这两个项目都是一个开发人员，所以我想知道是否可以将这两个项目放在同一个存储库中，或者为每个项目创建单独的存储库。我认为单独制作一个更好的主意，它看起来很干净而且因为它们不花费（就高清空间而言），所以为什么要担心呢？

【问题讨论】：

看看这个（重复？）问题：stackoverflow.com/questions/1761513/…
感谢 Sander Rijken，结束问题。
那里的“获胜”答案几乎是我自己的看法。
略有不同，另一个问题是关于公司中的多个开发人员，在我看来，这似乎是关于一个开发人员单独工作。如果@itsaboutcode 同意，也许只是编辑问题以强调这种差异？
@benzado 谢谢，我真的不确定，Sander Rijken 指出的问题即使对于单个开发人员也可以用作方向。但同样，这一切都取决于个人喜好。

标签： svn

【解决方案1】：

我倾向于每个可发布的存储库（一个库、一个可执行文件，或者可能是一个密切相关的库或可执行文件集）。为什么？我可以独立地标记和分支每个，而不必担心存储库中的结构以及该存储库中每个组件的状态。

我可以选择只签出特定的存储库（例如，对于客户端可执行文件）并简单地使用其他存储库的构建工件（库）。这对于团队中的简单管理员可能很有用，并将团队的重点放在特定的代码集上，而不是将它们暴露给企业使用的完整代码集（感谢您是独立开发人员，因此这可能不适用于您的情况！）

管理多个存储库的成本很低。它实现了分离，如果（例如）一个存储库用于构建其他组件使用的库或组件，这将非常有用。如果该库/组件有自己的存储库，那么您可以单独构建和版本化它，并发布它以供客户使用，他们知道他们正在使用构建工件而不是使用他们不应该使用的该库的子组件.我不确定您是否可以通过将所有内容都放在一个存储库中轻松实施这一点。

【讨论】：

您能在这种情况下解释“可释放”吗？你说的听起来很有趣，但我还没有完全理解。
可发布的将是库、可执行文件等。
您可以像创建^/ProjectA/trunk 和^/ProjectB/trunk 一样轻松地进行分支/标记，同时仍然可以重用代码。

【解决方案2】：

我为我所做的每个项目保留单独的存储库，并为我创建并打算重复使用的任何库保留另一个存储库。

就我而言，唯一真正的例外是我所有的简单 ruby 脚本都保存在一个存储库中。

这有助于使提交 cmets 更有意义，并保持单独的项目，嗯，单独是一个好主意，因为（除其他外）正如已经说过的那样，您永远不知道任何给定项目会发生什么。

【讨论】：

如果出现需要提取源的罕见情况，您仍然可以使用svnadmin dump 和转储过滤器。

【解决方案3】：

我认为如果有独立的两个项目分开是有利的：

您可以通过查看日志来跟踪项目进展
如果两个项目日志混合在一起，则更难找到您要查找的修订版（项目的先前版本）。
[EDIT] 与 subversion 相关的所有工具（例如 Trac 等项目管理工具）可能无法单独管理这两个项目。

【讨论】：

如果您在存储库的根目录中为每个项目创建目录，并在其下创建trunk/branches/tags，您可以轻松地检查每个单独项目的日志。
没错。但我不知道像 Trac 这样的项目经理系统如何单独管理这两个项目......（日志和其他功能......）

【解决方案4】：

我曾经是这样想的，但过了一段时间我开始发现一个项目中使用的一些代码可能对另一个项目有用（在不同的存储库上），所以现在我认为最好将所有内容放在一个存储库中。

【讨论】：

【解决方案5】：

我曾经将我的所有项目都放在一个大存储库中，但它变得有点混乱：如果不查看受影响的路径名，您无法判断哪个提交消息与哪个项目对应；对任何项目进行提交都会增加修订号，并在技术上使所有其他不相关项目的工作副本过时（即使没有要更改的更新文件）。

如果我在 SVN 服务器上工作，我不会介意，但这些只是我本地磁盘上的存储库。最终，我学会了如何使用 svndumpfilter 将它们全部分离到单独的、每个项目的存储库中。

如果你想在项目之间共享代码，我认为最好的办法是学习如何设置svn:externals 属性。在存储库中复制内容实际上并不比在磁盘上复制内容并多次检查更好。如果要将文件的更改传播到所有使用它的项目，您仍然需要做大量的手动工作。 svn:externals 允许您引用不同的存储库，因此您可以为共享代码创建一个存储库，然后为每个项目创建另一个存储库。

【讨论】：

当您设置一个指向 Common/Util 项目的 svn:externals 链接时，一旦 Common 项目稳定，最好使用特定版本而不是 HEAD。避免其他依赖项在技术上也过时。缺点是手动更新依赖项目中的引用。

【解决方案6】：

对于一个开发多个项目的开发人员来说，这些项目至少以某种方式相互关联，实际上开始使用一个大型存储库可能是有意义的，因为您可以轻松地切换和分支。

如果其中一个或多个项目可能是以后分离的候选者 - 例如如果一个团队可能会开始处理它们 - 考虑将项目从一开始就分开。这样，您就可以为每个项目提供干净的版本历史记录。（即不与其他项目的提交混合的历史记录。您始终可以使用转储工具过滤掉东西，但我发现不必这样做更方便。）

此外，如果有一天您的一项或多项作品可能会成为开源，那么拥有干净的版本历史记录是一件好事，因为像 ohloh 这样的社交编码网站会仔细检查您的提交，并添加到项目的活动统计信息和您的个人资料的专业知识中如果他们检测到您过去所做的实际提交。不是很重要，也没有真正讲述任何确凿的事实，但仍然很高兴。

Brian Agnew 在他的回答中提出了许多非常好的额外观点来支持分离。

在处理一个大型存储库时，您不应该遇到安全问题，如果有人开始参与存储库工作，您可以使用path-based authentication in Subversion。

但是，您必须使用与其相关的项目来标记每个提交，以便稍后从提交消息中理解。

【讨论】：