组织一个包含数千个元素的 Subversion 存储库
在开始之前：我花了很长时间在许多论坛上（包括 Stack Overflow - 是的，有很多关于组织 svn 的 SO 问题）、搜索 Google 和阅读文档（我拥有一些 Subversion 书籍）。 我仍然没有找到在 Subversion 中组织代码库的好方法。 我们目前使用 RCS 作为我们的版本控制系统，并且所有内容都存储在 1 个 RCS 目录中 - 丑陋，我知道 - 这就是为什么我正在努力实现更好的东西。 我也经常使用 Subversion，所以我知道它的功能以及它是如何工作的。 我几个月来一直犹豫着问这个问题，因为它与编程不完全相关，但由于我一直无法找到解决方案，还有什么更好的地方来问我的问题呢！
让我头脑中的事情变得复杂的是“项目”这个颠覆性的术语。 如果我想在 subversion 中管理一个 java 项目，这对我来说非常有意义：组合成 jar 文件的所有 java 文件都可以被视为一个“项目”——它们都属于在一起。 然而，在我们的环境中，我没有看到一种简单的方法来定义“项目”是什么。 我们有 4,000 多个程序，而且所有程序几乎都是相互独立的。 其中许多是 shell 脚本或 perl 脚本。 我们的一些脚本使用通用的“实用程序”或“库”脚本，但大多数情况下，所有代码对象都是独立的。
我们环境中的一个“项目”可能涉及程序 A、B 和 C，以及配置文件 AA。 另一个项目可以使用程序 C、D 和 E，以及配置文件 BB。 然而另一个项目可能只是更改配置文件 AA，或者可能是程序 B。没有办法对哪些程序或文件属于一个组进行分类。 因此 - 我不知道如何将我们的代码组织成颠覆。 我可以将所有内容放入主项目主干中，但检查工作副本意味着检查所有 4,000 多个元素。
为了提供一些背景信息，这是针对数据仓库的。 仓库功能需要全部 4,000 多个代码元素。 也许某个业务需求需要更改在一些元素中访问的列，而另一个业务需求需要更改一些其他元素（可能来自其他项目的一些相同元素）。
也许 Subversion 不是最适合我们的，尽管我必须相信它可以工作。 我们已经为我们的 Web 代码和 Java 程序提供了一个 Subversion 服务器，而且它运行得很好，因为有很容易定义的项目。 我只是不知道如何组织我们的主代码库。
希望其中一些是有道理的......提前感谢您的智慧！
Before I begin: I have spent a long time on many forums (including Stack Overflow - and yes there are a lot of SO questions on organizing svn), searching Google, and reading documents (I own a few Subversion books). I still have not found a good way to organize our code base in Subversion. We currently use RCS as our revision control system, and everything is stored in 1 RCS directory - Ugly, I know - that's why I am working towards something better. I have also used Subversion a lot, so I know it's capabilities and how it works. I have hesitated asking this question for months, since it is not completely programming related, but since I haven't been able to come to a solution, what better place to ask my question!
What complicates things in my head is the subversion term "Project". If I want to manage a java project in subversion, this makes perfect sense to me: all of the java files that get combined into a jar file could be considered a "Project" - they all belong together. However, in our environment, I do not see an easy way to define what a "project" is. We have over 4,000 programs, and all of them are pretty much independant of each other. Many of them are shell scripts or perl scripts. Some of our scripts use generic "utility" or "library" scripts, but for the most part, all code objects are indepenant.
One "Project" in our environment could involve program A,B, and C, and config file AA. Another project could use programs C,D, and E, and config file BB. Yet another project could just be changing config file AA, or maybe program B. There is not a way to classify which programs or files belong in a group. Because of this - I have no idea how to organize our code into subversion. I could put everything into a master project trunk, but then checking out a working copy means checking out all 4,000+ elements.
To give some context, this is for a Data Warehouse. All 4,000+ code elements are needed to make the warehouse function. Maybe a certain business requirement comes in that requires changes of a column that is accessed in a few of the elements, and another business requirement requires changes to a few other elements (maybe some of the same from the other project).
Maybe Subversion isn't the best fit for us, although I have to believe it can work. We already have a Subversion server for our web code and our Java programs, and it works great, because there are easily defined projects. I just can't figure out how to organize our main code library.
Hopefully some of that made sense... Thanks in advance for your wisdom!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以查看外部财产。 它允许您定义附加此属性的目录的检出，还将检出存储库中的其他位置到该目录的子目录。
因此，您可以为每个组件创建“真实”目录，然后为每个项目创建单独的目录，该目录将使用外部来签出所需组件。
You might look at the externals property. It allows you to define that checkout of directory to which is this property attached, will also checkout other locations within the repository to subdirectories of that directory.
So you might create "real" directory for each component and then create separate directory for each project which will use the externals for checkout of required components.
在将文件转储到颠覆存储库之前，我会尝试组织文件的文件夹结构。
我认为你的问题主要在于现有文件的混乱。 如果您能找到一种方法将系统逻辑地划分为多个部分，那么允许人们只检查文件块（这些文件将在逻辑分组中）会更容易。
Subversion确实镜像了一个文件系统，所以如果它在文件系统中看起来不漂亮，那么它在subversion中看起来也不会漂亮。
如果您想避免重新组织文件，也许您可以找到一个版本控制系统，它可以让您根据标签签入/签出内容，而不是根据它们在文件系统中的位置。
I would try to organize the folder structure of the files before simply just dumping it into a subversion repository.
I think your problem mainly lies in the disorganization of the existing files. If you can find a way to logically divide up your system into segments, then it would be easier to allow people to only check out chunks of files(which would be in logical groupings).
Subversion really mirrors a filesystem, so if it doesn't look pretty in a filesystem, it won't look pretty in subversion either.
If you want to avoid reorganizing files, perhaps you can find a version control system that lets you check in/out things based on tags, instead of where they are in the file system.