多个存储库还是带有分支的单个存储库？
我已经在一个项目上工作了一段时间，它已经分为几个不同的版本。所有版本都有一些通用的代码库，每个版本都有独特的特定功能，并且每个版本都需要单独支持。
您推荐哪种 SVN 结构？现在我为每个项目使用单独的存储库，但这样做的缺点是对于大量产品来说这是不切实际的。使用带有分支的单个存储库的缺点是，无论从哪个分支提交任何内容，它都会向每个分支添加修订号。
在这种情况下您/您会使用什么设置？
I have been working on a project for some time, and it has branched off into several different versions. All versions have some common code base, and each version has specific functionality that is unique, and each version will need to be supported individually.
What SVN structure would you recommend? Right now I am using a separate repository for each project, but the downside of that is that it is impractical for large number of products. The downside of using a single repository with branches is that it would add revision numbers to every branch whether anything was committed, regardless from which branch.
What setup do you/would you use in this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
绝对是同一个存储库。由于存在通用功能，因此您通常会将代码从一个项目移动到另一个项目。在存储库内移动文件会保留其历史记录，而跨存储库移动文件则不会。
我不明白为什么对分支跳过编号进行修改会出现问题。
供参考：在工作中，整个软件工程部门（60个编码员）的所有项目都在同一个svn存储库中。
Most definitely the same repository. Since there is common functionality, you will commonly move code from one project to the other. Moving files within a repository retains their history, moving them across repositories doesn't.
I don't see why having revisions on a branch skip numbers would be problem.
For reference: At work, all projects from the entire software engineering department (60 coders) are in the same svn repository.
一个存储库。沿途分支和标记。一旦习惯了，这确实不是问题。
有一些良好的发布管理实践将有助于这一点（例如跟踪哪个版本/分支具有哪个功能等）
One repository. Branch and tag along the way. It really is not problematic once you get used to it.
Have some good release management practices and will help this (e.g. track which version/branch has which feature, etc.)
您首先应该做的第一件事是确保您的组件结构（将程序构建为松散耦合库的方式）反映了您的需求。
当您在一个或多个单独的库中拥有通用代码以及其他代码（但与通用代码明显分开）时，事情会变得容易得多。然后，您可以像处理单独的产品一样处理公共代码，并将不同的“版本”（如您所称的）作为单独的程序来处理，每个程序都使用公共库的特定修订版。
话虽如此，两种方法（单独的存储库或一个大的单一存储库）都可能有效。如果您的不同“版本”必须真正分开，因为它们适用于具有不同支持协议的不同客户，恕我直言，单独的存储库会更好（一个用于每个产品，一个用于您的公共库），因为您可以更轻松地避免不需要的方面不同版本之间的影响。另一方面，如果情况不同，将所有内容都放在一个存储库中可以为您节省大量管理工作，例如，当您经常需要将代码从公共库移动到其他组件之一时，反之亦然。
例如，在我们公司，我们有一个用于销售给其他公司的软件产品的存储库，还有一个用于我们内部软件的存储库。显然，我们对这两类软件的支持需求非常不同。当我们需要在内部代码中重用产品中的库时，我们编写了一些简单的脚本来检查库的特定版本并将其复制到内部代码的构建环境中。我们尽量避免内部软件开发对产品开发产生太大的影响，但是当内部有明确属于公共库的需求时，我们就添加到那里，结合我们的产品进行测试，当它起作用时，我们更新脚本以获得新版本。
The one first thing you should do first is to make sure that your component structure (the way you have structured your program into loosely coupled libraries) mirrors your requirements.
Things go a lot easier when you have the common code in one or more separate libraries, and the other code too (but clearly separated from the common code). Then, you can handle your common code like a separate product, and your different "versions" (as you call them) as separate programs, each one using a specific revision of the common library.
Said this, both approaches (separate repositories or one big single repository) might work. If your different "versions" have to be really separate, because they are for different customers with different support agreements, IMHO separate repositories will work better (one for each product and one for you common library), because you can more easily avoid unwanted side effects between the different versions. On the other hand, if the situation is different, having all things in one repository can save you a lot of administrative work, for example, when you often have to move code from the common libary to one of the other components, or vice versa.
For example, in our company, we have one repository for a software product sold to other companies, and one for our in-house software, Obviously, we have very different support needs between those two types of software. When we got to the point where we needed to reuse a library from our product in the in-house code, we wrote some simple scripts to check out a specific revision of the library and copy it to the build environment of the in-house code. We try to avoid too much influence from the in-house software development to the product development, but when there is a requirement from in-house that belongs clearly to the common library, we add it there, test it in combination with our product, and when it works, we update our script to get the new revision.
如果它们都是同一代码库的不同版本，那么我会将它们放在分支中（在单个存储库中）。
我通常只为不同程序使用新存储库。
If they are all different strains of the same code base, then I would put them in branches (in a single repository)
I generally only use a new repository for different programs.
我使用 GIT 是因为它可以更好地处理分支和合并:) 但对于 SVN 来说，这取决于项目的数量以及它们之间的关系。如果代码都是同一个程序的一部分，我会做不同的分支。
如果它们是独立的项目，那么您会想要使用不同的存储库。
I use GIT because it handles branching and merging a lot better :) But for SVN it would depend on how many projects and how they are related. If the code is all part of the same program, i'd do different branches.
If they are isolated projects then you'd want to use different repositories.
一种方法是为通用核心功能设置一个存储库，并为每个项目设置一个存储库，该项目取决于进行自定义的核心。您可以让您的子项目使用 svn:externals 定义< /a>.
这假设核心功能足够模块化以支持这种隔离。
One way would be to set up a repository for the common, core functionality and a repository for each project that depends on the core where the customizations would be made. You can have your child projects pull the core files in using an svn:externals definition.
This assumes that the core features are modular enough to support this isolation.
就我个人而言，我建议使用 DVCS （不是为了阻止您使用 subversion），并为每个项目拥有一个单独的存储库。
如果存在共同的历史记录，那么这些存储库就可以相关。 如果您以前从未使用过 DVCS，我建议您使用 Mercurial，因为它非常容易学习，并且在 Windows 和 Linux 上运行得同样好。
Personally, I would suggest using a DVCS (not to deter you from using subversion) and have a separate repository for each project.
If there is common history, then these repositories can be related. If you've never used a DVCS before, I'd suggest Mercurial because it is quite easy to learn and works equally well on Windows and Linux.
除了所有推荐分支而不是多个存储库的建议之外，增加未受影响分支的修订版本号并不是真正的缺点。
In addition to all those that recommend branches rather than multiple repositories, having increasing revision numbers for unaffected branches is not really a downside.
我会选择一个具有多个分支的存储库。我认为您不必担心修订号 - 为您的分支提供良好的名称和名称。使用标签来引用外部的不同部署。 （例如 - 为分支 A 的构建 3 创建一个标签）这样，在内部处理 SVN 时您只需要担心修订号。
I'd go with a single repository with a number of branches. I don't think you should have to worry about the revision numbers - give your branches good names & use tags to reference different deployments externally. (e.g. - make a tag for build 3 of branch A) That way, you only need to worry about revision numbers when dealing with SVN interally.