我是颠覆和版本控制概念的新手，虽然我可以处理一些项目中的一些文件，我需要一些关于如何根据我的需求进行扩展的建议。
基本上我们正在开发一个环境，其中包含许多脚本和配置，这些脚本和配置分布在许多虚拟和物理机器上。构建脚本，配置文件，二进制文件，RPM镜像等......虽然每个人在他们自己的世界中都可以，但我们需要一些方法将它们聚合成一个版本。虽然在一个更大的编码项目中我看到这可能只是处理单个SVN项目中的文件夹（据我所知，所以可能不是......）这些thigns真的没有任何共同之处，许多甚至不是代码，并且只是在SVN中作为我想象的占位符。因此，“检查”组装的数据量是没有意义的，但不知何故需要将顶级版本号与60个不同的工作相关联。如上所述，这是代码，配置文件，rpm等。
我最初假设我们会以某种方式使用SVN，但在第一种情况下这可能是错误的假设。但是，从我对需求的一般目的看，我可以想象在SVN中有实际项目，然后在cronjob（或其他触发器）上更新的包装项目，以引用元数据文件中列出的每个项目的最新SVN版本包装项目。如果列表中的任何项目已更改，则更新该包装器项目，并在其中检入新的元数据文件。反过来，这些包装器被其他包装器包装起来直到一个主项目。该主项目版本的最终用途是建立其下的项目基线，该基线可以与文档和变更跟踪系统一起使用，并具有自动化水平。
虽然我可以设想我刚刚描述的内容，但它只是基于一个非常小的SVN视图，并且可能（希望）错过了很多SVN（或git .... ??）存在的观点。 / p>
我希望这是有道理的，如果没有，我很抱歉。非常乐意尝试澄清任何事情。
由于
克里斯
编辑：举例说明我们需要涵盖的各种事项：
我并不关心这些事情是如何完成的，更多的是我们如何在部署时提供对这些事物的每个版本的看法。
[编辑]好的，这一切归结为我并不真正了解svn版本。由于版本号是存储库范围，所有项目都隐含地被覆盖......根本不需要实际工作来实现我想要的。谢谢，难怪我对其他任何人都没有多大意义..
答案 0 :(得分：1)
你想要的是SVN Externals
答案 1 :(得分：0)
我不确定我是否理解这个问题，但你可以在SVN的不同目录中存储许多不同的东西。然后，您可以使用sparse directory功能来获取存储库的一部分。
因此，如果您选择，您可以单独存储每台机器的配置，并且只检查特定机器上该机器的目录。
在SVN中不能做的是在2个不同的地方显示相同的文件。因此，您无法将abc.config存储在顶级目录中，然后在2个不同的目录树中查看该确切文件。但是，您可以使用外部效果执行此操作。