您的 SVN“项目”的粒度如何：一个包含多个相关应用程序的大项目或一个“项目”？ 每个应用程序
我将项目定义为包含主干、分支、标签子目录的 SVN 目录。
在确定何时将一个项目拆分为两个或将多个项目合并为一个时，您使用什么标准？ - 每个“项目”一个应用程序，具有公共源和资源的共享项目？ - 一个包含应用程序所有源代码和资源的大型“项目”？
单个项目或多个项目都有其优点和缺点。 我们正在朝着一个单一的项目迈进，我正在尝试弄清楚这是否是正确的方法。
拆分项目可以更好地控制套件的不同部分如何合并更改。 公共库可以是版本的，不同的应用程序可以选择使用特定的版本（maven dep管理方式）。
拆分项目还会创建多个类层次结构，使代码更难以整体理解，并可能导致代码重复。 我认为整体结构和组件之间关系的正确设计将是管理此成本的关键。
统一的项目方法将使开发人员更轻松地设置工作区，并提供单一的类层次结构。 这是一把双刃剑，因为它还会向开发人员提供更多信息（太多的类难以理解）。
那么，当您尝试决定在哪里合并和在哪里拆分时，您会使用什么经验法则？
I define a project as an SVN directory containing trunk, branches, tags sub dirs.
What criteria do you use when determining when to split a project into two or consolidate several projects into one?
- One App per "Project" with a shared projects for common source and resources?
- One big "project" containing all source and resources for the app?
Single project or multi project both have their pluses and minus. We are heading more towards a single project and I'm trying to figure out if this s the right approach.
Split projects allow greater ability to control how different parts of the suite incorporate a change. The common library can be version and different applications can chose to use a specific version (maven dep management approach).
Split project also create multiple class hierarchies making the code more difficult to understand as a whole and potentially leading to code duplication. I would assume that proper design of the overall structure and the relationships between components would be key to managing this cost.
A unified project approach will make it easier on the developer in terms of setting up a workspace, and provide a single class hierarchy. This is a double edged sword as it will also throw much more information at the developer (too many classes to comprehend).
So, when you are trying to decide where to combine and where to split, what rules of thumb do you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我们将与单个应用程序相关的所有项目放在一个 SVN 代表中，只是为了便于维护，将应用程序的代码库集中在一个存储库中，并且能够管理应用程序不同资源之间的相互依赖关系。
我们通常将资源分类到主干中的不同文件夹中。 该分类主要基于功能/模块分组或分层分组 [DAL、BLL、GUI 等]。 这完全取决于您如何构建代码。 希望这可以帮助。
We put all the projects related to a single app within one SVN Rep simply for the sake of ease of maintenance, centralizing the app's code base in one repository only and also ability to manage the interdependencies between different resources of the app.
we generally categorize our resources into different folders within trunk. that categorization is primarily based on the functional /modular grouping or layered grouping [DAL, BLL, GUI, etc.]. that is completely upto how you have structured the code. Hope this helps.
SVN 书籍 对这两种方法进行了很好的讨论。
最后，我会选择对存储库用户来说更自然的选择。
就我个人而言，我更喜欢使用单一 SVN 主干/标签/分支方法，将所有实际代码项目放在它们自己的文件夹中。
然而，对于更大的代码库（我只管理过 3-4 个小型项目，它们是单个解决方案的一部分），我会高度考虑更改为拆分方法。
The SVN Book has a good discussion on both approaches.
In the end I would choose whatever feels more natural to repository users.
Personally, I've favoured a single SVN trunk/tags/branches approach with all my actual code projects in their own folders inside those.
However, for a larger code-base (I've only managed 3-4 small projects which were part of a single solution), I would highly consider changing to a split approach.
我根据项目规模使用单独的项目和组合项目。 对于我们的大型项目，每个项目都位于单独的存储库中，并且具有独立的构建和部署过程。 对于我们较小的项目，我们有一个“工具”存储库来包含它们，每个子项目作为根目录的子目录。
我还维护一个“个人”存储库，人们可以在其中存储他们的测试程序一次性实用程序，或者可以从源代码控制和集中备份中受益的其他东西，但不属于独立项目。
I use both separate projects and combined projects depending on project size. For our large projects, each one is in a separate repository, and has independent build and deployment procedures. For our smaller projects we have a "tools" repository to contain them, with each sub-project as a subdirectory of the root.
I also maintain a "personal" repository where people can store their test programs one-off utilities, or other things that could benefit from source control and centralized backups, but does not belong as an independent project.
我使用单独的项目并通过 svn:externals 将它们组合起来形成一个解决方案。
I use separate projects and combine them to form a solution through svn:externals.
每个项目独立部署的一个应用程序/模块。 如果您发现需要使用依赖于其他模块稳定实现的模块进行 Maven 式依赖管理，那么使用单个项目将很难引入发布周期。 它还可能导致人们直接使用其他应用程序中随机的看起来有用的代码，而不是将其分解出来以保持依赖关系图的健全（tm）。
您应该使用正确的测试套件和明确定义的 CI 实践来进行集成测试，而不是依赖于如果某个部分出现故障，一半的代码会突然失败。
拥有单个 uber-project 的另一个问题是，对于只在单个模块上工作的 git-svn 用户来说相当繁重。
One app / module that is deployed independently per project. Using a single project makes it difficult to introduce release cycles if you ever find out you need Maven -ish dependency management with a module depending on stable implementations of other modules. It can also lead to people just using random useful-looking code from other apps directly instead of factoring it out to keep the dependency graph Sane (tm).
You should do integration testing using proper test suites and CI practices at clearly defined , not by relying on half your code failing all of a sudden if one part breaks.
Another problem with having a single uber-project is that it's rather onerous for git-svn users that only work on a single module.
有机成长。 Dijkstra 曾经说过，预优化是万恶之源。 还要记住 YANGI（你不会需要它）。
每个应用程序都有自己的文件夹，其中包含 trunk/tag/branches。 如果应用程序中的项目变得非常大，那么它会被推送到它自己的单独文件夹中，并且可以在构建时链接到应用程序（甚至 svn:externals）。
也就是说，如果您的项目要求是开发由 10 名开发人员编写的复杂应用程序，并且您是看门人或构建大师，那么您可以考虑更复杂的替代方案。
Grow organically. Pre optimization is the root of all evil, Dijkstra once said. Also keep YANGI (you ain't gonna need it) in mind.
Every application gets its own folder with trunk/tag/branches. If the a project within an application gets really big, then it gets pushed to it's own separate folder and can be linked to the application at build time (or even svn:externals).
That said, if your project requirements are to develop a complex application written by 10 developers and you are the gatekeeper or build master then you can consider more complex alternatives.
为不同的项目保留单独的 SVN 存储库。 您最不想看到的就是 合并日
Keep separate SVN repositories for separate projects. The last thing you want is to have a Merge Day
您可能需要查看跨多个项目的 Subversion 修订版本号 。
You might want to check out Subversion revision number across multiple projects.
感谢您的意见。 我不会“选择”一个答案，因为我认为每个答案都有有价值的观点。 避免过早的优化似乎很关键，就像暂时保持布局尽可能简单一样。 我们正在转向包含应用程序的单个项目，因为 90% 的时间我们都是一起发布的。 因此，每个项目一个应用程序使问题变得复杂似乎没有意义。 即使我们使用 Maven，给定版本的所有 Maven 工件也可能来自同一个分支。 如果需要使用 SVN 历史记录和鱼眼来保持理智，我们可以随时更改它。
我们将重构源布局，就像重构源一样。 当一个项目因周长和依赖情况而开始“闻起来很糟糕”时，我们会分解它，但在此之前不会。 我可能会使用时间周长而不是空间周长：构建和构建的时间 测试，结账时间。 如果我有一个 1GB 的树，我可以在 << 中签出。 10 分钟并在 << 中构建/测试 30 分钟 我真的不需要把它分解，除非我需要经常释放它的一部分。
所以，感谢您的意见。 这对于我为我的团队提出问题和评估选项确实很有帮助。
Thanks for the input. I won't "choose" an answer because I think all have valuable points in them. Avoiding premature optimization does seem key as does keeping the layout as simple as possible for the time being. We are moving to a single project containing the apps because 90% of the time we release ALL together. Therefore, to complicate matters with a one-apps-per-project doesn't seem to make sense. Even when we go to maven it is likely that all maven artifacts for a given version will be made from the same branch. We can always change it later if need be using SVN history and fisheye to keep us sane.
We'll refactor the source layout just like we'd refactor the source. When a project starts to "smell bad" from a girth and dependency situation we'll break it up, but not before that. I'll probably use girth in time not girth in space: time to build & test, time to checkout. If I have a 1GB tree that I can checkout in < 10 minutes and build/test in < 30 minutes I don't really need to break it up unless I am required to release parts of it frequently.
So, thanks for the input. It was really helpful in my framing the question for me team and evaluating options.
这里没有“好的”答案，但我认为包含 1 或 2 个项目的 SVN 存储库与包含 100 个项目的其他 SVN 存储库之间应该有所区别。
我维护一个从 VSS 迁移的 SVN 存储库，它有数百个“项目” ” 其中，它们都没有按照 trunk/branch/tag 结构进行组织（事实上，在我使用 SVN 一段时间后，我认为这种结构确实没有必要，也没有什么帮助，当你必须这样做时，它当然没有帮助将 2 或 3 个项目标记为单个更改）。
我们为所有维护的软件维护一个项目目录，在该目录下有用于配置的子目录和另一个用于源代码的子目录。 在这些下，我们有产品版本号 - 因此我们有效地抛弃了主干的概念，我们只有标签目录 - 最高的数字是主干（我们必须这样做，因为我们必须同时支持项目的多个版本）。 合并根据需要进行，因此如果我更新项目 A 版本 3.0 中的错误； 我会将这些更改合并到版本 4.0 和 v5.0。
如果我要做一个只有 1 或 2 个项目的存储库，我可能会想保留分支/标签结构，但另一方面 - 我可能会在主树中显式地保留目录（假设我没有发布频率足以定期标记）（顺便说一句，我使用修订号作为“标签”，并将二进制文件存储在其中。因此，如果我需要获取特定的旧版本，我可以通过查看日志来获取正确的二进制文件）
考虑到我有一个 10Gb 存储库，其转速目前超过 300,000，其中有大量旧代码和新代码，管理起来出奇地容易。 我会向其他人推荐该结构并将再次使用它。
顺便说一句，标签目录对我们不起作用的另一个原因是，每次出现错误或更改请求时我们都会发布，无论多么小。 一段时间后，我们的标签目录将无法管理，这就是我们使用 revnum 作为标签的原因 - 我们可以将它与错误跟踪器关联起来，以使其更易于人类阅读。
粗略地总结一下，我们有一个像这样的目录结构，其中 v1 和 v2 是产品版本：
显然，我们可以在“源”下放置一个分支目录，并在每个子项目下放置一个分支/标签，但是如果我们需要将 2 个子项目作为单个变更请求发布（正如我们经常所做的那样）。 将标记子目录放在源目录下意味着我们在只有一个子项目发生更改时标记所有内容（不符合我们单独跟踪每个子项目的要求）
there's no 'good' answer here, but I think there should be a distinction made between SVN repos that contain 1 or 2 projects, and others that contain 100.
I maintain a SVN repo that was migrated from VSS, it has several hundred "projects" in it, none of them have been organised along the trunk/branch/tag structure (in fact I think that structure is really unnecessary and unhelpful after I've used SVN for a while, it certainly doesn't help when you have to tag 2 or 3 projects as a single change).
We maintain a project directory for all our maintained software, under that we have subdirs for configuration and another for source. Under those we have product version numbers - so effectively we are throwing away the concept of trunk, we only have tag directories - the highest number being the trunk (we have to do this as we have to support several versions of the projects simultaneously). Merging happens as needed, so if I update a bug in project A, version 3.0; I'll merge those changes to version 4.0 and v5.0.
If I were to do a repo with just 1 or 2 projects, I may be tempted to keep the branch/tag structure, but on the other hand - I'd probably keep the directories explicit in the main tree (assuming I didn't release often enough to tag regularly)(I use the revision number as a 'tag' BTW, and I store binaries in there. So if I need to get a particular old revision, I can grab the right binary from looking at the log)
Its surprisingly easy to manage considering I have a 10Gb repo with a revnum currently up past 300,000 with lots of old code in there as well as newer. I would recommend the structure to others and will use it again.
Incidentally, one other reason tags dir wouldn't work for us is because we release every time there is a bug or change request, no matter how tiny. Our tags directory would be unmanageable after a while, this is why we use the revnum as a tag - we can associate it with the bug tracker to keep it more human readable too.
So to summarise in rough, we have a directory structure like this where v1 and v2 are product versions:
obviously, we could put a branch dir under 'source', and a branch/tag under each subproject too but that would become tricky if we needed to release 2 subprojects as a single change request (as we do quite often). Putting a tag subdir under the source dir would mean we tag everything, when only a single subproject got changed (doesn't fit with our requirement to track each subproject individually)