2

使用版本控制系统的在线界面是为最新版本的代码提供发布位置的好方法。例如，我在这里有一个 LaTeX 包（只要验证更改为实际工作，它就会发布到 CTAN）：

http://github.com/wspr/pstool/tree/master

包本身源自一个文件（在本例中为 pstool.tex），该文件在处理时会生成文档、自述文件、安装程序文件以及构成 LaTeX 使用的包的实际文件。

为了方便想要下载这些东西的用户，我在存储库本身中包含了上面提到的所有派生文件以及主文件 pstool.tex。这意味着每次提交时我都会进行双倍的更改，因为包文件 pstool.sty 是主文件的生成子集。

这是版本控制的变态吗？

@Jon Limjap提出了一个很好的观点：

您是否有另一种方法可以将生成的文件发布到其他地方以供下载，而不是依靠您的版本控制作为您的下载服务器？

这才是本案真正的症结所在。是的，可以从其他地方获得该软件包的已发布版本。因此，仅对非生成文件进行版本控制确实更有意义。

另一方面，@ Madir的评论是：

真实的、重复的便利超过了幕后承担的成本

这也是相当相关的，如果用户发现错误并且我立即修复它，他们可以前往存储库并获取他们继续工作所必需的文件，而无需运行任何“安装”步骤。

我认为，这对于我的特定项目集来说是更重要的用例。

4

5 回答 5

4

我们不对可以使用存储库本身中包含的脚本自动生成的文件进行版本控制。这样做的原因是在结帐后，这些文件可以通过单击或命令来重建。在我们的项目中，我们总是尽量让这一切变得简单，从而避免对这些文件进行版本控制。

我可以想象一种情况，如果“标记”产品的特定版本，用于生成输出所需的工具可能不可用的生产环境（或任何非开发环境），这可能会很有用。

我们还在构建脚本中使用目标，这些目标可以使用我们产品的发布版本创建和上传档案。这可以上传到生产服务器或 HTTP 服务器以供您产品的用户下载。

于 2008-09-02T10:21:06.327 回答
2

我正在使用 Tortoise SVN 进行小型系统 ASP.NET 开发。大多数代码都被解释为 ASPX，但手动编译步骤生成了大约十几个二进制 DLL。虽然理论上对这些源代码进行版本化没有多大意义，但确保它们从开发环境正确镜像到生产系统（一键式）确实很方便。此外 - 在灾难的情况下 - 回滚到上一步再次在 SVN 中单击。

所以我硬着头皮将它们包含在 SVN 存档中 - 真实且重复的便利性超过了幕后承担的成本。

于 2008-09-02T10:25:26.237 回答
1

不一定，尽管出于显而易见的原因，源代码控制的最佳实践建议您不要包含生成的文件。

您是否有另一种方法可以将生成的文件发布到其他地方以供下载，而不是依靠您的版本控制作为您的下载服务器？

于 2008-09-02T10:10:44.027 回答
1

通常，派生文件不应存储在版本控制中。在您的情况下，您可以构建一个发布过程，该过程创建一个包含派生文件的 tarball。

正如您所说，将派生文件保留在版本控制中只会增加您必须处理的噪音量。

于 2008-09-02T10:13:51.617 回答
0

在某些情况下我们会这样做，但它更像是一种系统管理员类型的用例，其中生成的文件（例如，从脚本构建的 DNS 区域文件）本身就具有内在的兴趣，并且修订控制是线性审计跟踪而不是分支和标记源代码控制。

于 2008-09-02T10:44:50.917 回答