管理源控制系统中程序所有权的有效方法是什么？

Question

使用SVN或Git，我想到了将目录结构用作元数据占位符。每个团队在共享存储库中都有一个目录用于代码。我想的越多，但想法似乎越糟糕。对我来说这似乎是一个坏主意的原因是团队不是静态实体。团队可以消失，分裂，重组，甚至获得新名称。我知道我正在考虑使用唯一标识符，可能还有外部数据库。我甚至可能面对每个团队存储库来适当地管理访问权限。在拥有200个或更多团队的情况下，我最好是在外部数据库中维护所有权还是我可以从中学到一些工具和实践？

Answer 1

这是我向你指出正确方向的最佳尝试。一般来说：

以常规方式根据系统组件组织源代码。确保每个组件都可以独立配置访问控制（例如，在git中，这意味着每个组件都有单独的存储库，如Makis所说）。

管理访问权限通常与LDAP结合使用。配置您的工具以通常的方式利用组织的LDAP目录。 （对于git，这通常是使用系统上的现有帐户完成的，这些帐户可能会或可能不会由LDAP支持。）

以通常的方式使用版本控制系统的内置访问控制机制，以允许每个团队根据需要读取或写入每个组件。如果此权限矩阵变得过于繁琐而无法手动管理，请构建自定义机制以在更高级别控制它和/或自动执行大规模更新。

如果您没有VCS的组件体系结构，集中式用户帐户或访问控制，请放弃此问题，直到您修复更重要的问题为止。

Answer 2

以下是我看到它的完成情况。沿相关技术行对齐目录结构。这可能是现在基于团队的。使用数据库或其他东西将二进制文件（或源文件）映射到团队成员。然后，当事情四处移动时，您所要做的就是更新数据库。

如果你的根目录非常广泛，那么你的重组次数要少于你把它缩小的时间。

Answer 3

Git不能很好地访问权限。要开始处理它，你需要使用gitosis然后将一些代码写入git钩子。我对此有一个question。

然后，如您所说，您需要一个数据库来处理有关哪个用户可以访问哪个存储库的信息。即你需要将这些东西拆分成git中的单独存储库，因为你无法保护git中的单个文件或目录。我前段时间写了一篇简短的blog note。超级项目可能在将来有所帮助，但这个概念仍在建设中，并没有很好的定义。

在像Rational ClearCase这样的更高级（和昂贵的）SCM工具中，你有更好的工具。例如，您可以创建组件并定义每个组件的用户权限。不幸的是，如果情况发生很大变化，即使是这些工具也需要手工进但是，如果您只需要用户权限，那么编写自己的工具而不是购买其中一个怪物会更具成本效益。

Answer 4

阅读你的问题我有一个想法，这对你有用（或者不是，它只是一个突然出现在我脑海中的闪光想法; - ）：

1. 与linux的“devtodo”工具一样，您可以在每个目录中为元数据创建一个文件。 （对于devtodo，该文件名为'.todo'）
2. 该元数据文件可以是nosql数据库文件，当时是团队成员。
3. 该元数据文件可以是控件版本。
4. 该元数据文件可以与其他文件（即团队中的所有成员）连接（作为sql join操作）。
5. 可以定义一组脚本或shell别名来编写更频繁使用的nosql命令行。

在几行中：git或svn中的关系数据库文件与您的元数据;没有数据库服务器。

Answer 5

您要存储的元数据是保存有关文件和使用资源的团队成员的信息。假设您的存储库中有成熟的资源处理语义，例如签入注释等，一种策略可能是识别您正在查看的元数据，并使用某些索引工具/ api对其进行索引。存储库元数据中提供了大量信息，可以检索和索引这些信息。如果您需要更好的控制，您可以使用自定义的预提交挂钩来强制团队成员在签入时放置所需的信息。您将拥有的元数据存储库可以很好地控制查询/搜索用户和资源。索引可以每天/每周由脚本执行。

Answer 6

为每个团队提供自己的存储库。

Answer 7

好的，如果我正确地理解了你的问题那么你就有了 1.多个程序
2.处理源代码的多个团队
3.需要跟踪哪些团队正在处理哪些代码

您不指定每次只对一个程序或该程序是否有效 可以由多个团队协同工作。

我不是GIT或SVN用户，我的主要经验是perforce，但我会尝试概述一些适用于任何大型企业级SCM系统的最佳实践

1. 有一个主线代码分支 - 这将是你的“干净”区域。
2. 为每个团队创建一个沙箱分支
3. 使用明确的命名约定

每个团队沙箱只拥有该沙箱的完全访问权限，但不能访问任何其他团队的沙箱。

所以在存储库布局方面，有类似的东西

• 码
  • 主线
    • program1
    • program2
  • 队
    • teamA
      • program1
    • teamB
      • program2

然后，每个团队都会将他们想要工作的内容的代码分支到他们的团队沙箱中，并随意签入他们喜欢的任何内容。如果他们把他们自己的分支弄脏了那就好了，他们的问题就是在他们自己之间进行梳理并运行他们认为合适的方式。

一旦团队满意，他们的下一代代码就会很好，只有团队负责人 有权促进和整合更改到主线

任何体面的SCM都会向您显示集成历史记录，因此对于每个升级到主线的更改，您都会知道哪个团队是集成的，何时集成。

如果团队解散，那么如果你愿意，可以放弃分支 如果团队名称发生更改，则为新团队创建新的sanbox分支，然后将旧团队沙箱中的更改集成到新沙箱中

在perforce上你可以做一些时髦的东西，比如反向集成，这非常好，因为你可以将主线拉入你的分支，进行任何合并然后集成回主线。只要代码上没有其他任何改变，那么集成就变成了一个直接的副本。这样做的好处是可以将“破损”主线向下推入沙箱并保持主线清洁

无论如何，这是我的一些想法。 SCM管理本身就是整个领域，我相信很多其他人会有更好的解决方案，但上述方法对我有用

这个复杂领域的一些有用的链接:)
Software Life Cycle Modelling
High-level best practices in SCM
SCM intro - repositories
SCM intro - branches

Answer 8

如果它是一个单独的项目，只需给它一个自己的存储库。