代码之家 › 专栏 › 技术社区 › Will Robertson

您是否版本“派生”文件?

revisions revision-history versioning version-control

2

Will Robertson · 技术社区 · 16 年前

使用版本控制系统的联机接口是获得最新版本代码的发布位置的好方法。例如,我这里有一个乳胶包(当更改被验证为实际工作时,它会发布给CTAN):

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

包本身是从单个文件(在本例中是pstool.tex)派生而来的,该文件在处理时会生成文档、自述文件、安装程序文件,以及组成包的实际文件,正如乳胶使用的那样。

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

这是版本控制的歪曲吗?

@ Jon Limjap 提出了一个好观点:

是否还有其他方法可以将生成的文件发布到其他地方进行下载,而不是依靠版本控制作为下载服务器?

这才是这件事的关键所在。是的,包的发布版本可以从其他地方获得。因此,只对未生成的文件进行版本控制确实更有意义。

另一方面,@ Madir 的评论:

真正的、重复的便利,胜过幕后的成本。

如果一个用户发现了一个bug,并且我立即修复了它,那么他们就可以直接访问存储库并获取继续工作所需的文件,而无需运行任何“安装”步骤。

我认为这是更重要的用例 对于我的一组特定项目 .

5 回复 | 直到 9 年前

1

2

Madir 16 年前

我正在使用Tortoise SVN进行小型系统ASP.NET开发。大多数代码是解释ASPX的,但是有大约12个二进制DLL是由手工编译步骤生成的。虽然理论上对这些源代码进行版本控制没有多大意义,但它确实使确保它们从开发环境正确镜像到生产系统(单击一下)变得很方便。另外,在发生灾难的情况下,回滚到上一步是再次单击SVN。

所以我咬了一口子弹,把它们放进了SVN的档案中——方便是真实的,重复的,超过了成本,这是在幕后承担的。

2

4

Kamiel Wanrooij 16 年前

我们不支持使用存储库本身包含的脚本自动生成的版本文件。原因是签出之后,可以通过单击或命令重新生成这些文件。在我们的项目中,我们总是尽可能地简化这一过程,从而避免了对这些文件进行版本控制的需要。

我可以想象的一个场景是,如果为产品的特定版本添加“标签”,在生产环境(或任何非开发环境)中使用,而生成输出所需的工具可能不可用,那么这一点会很有用。

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

3

1

Jon Limjap 16 年前

不一定,尽管源代码管理的最佳实践建议您不要包含生成的文件,原因很明显。

是否还有其他方法可以将生成的文件发布到其他地方进行下载,而不是依靠版本控制作为下载服务器?

4

1

Greg Hewgill 16 年前

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

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

5

0

robc 16 年前

在某些情况下,我们会这样做,但它更多的是一种系统管理类型的用例,在这种用例中,生成的文件(例如,从脚本构建的DNS区域文件)对其自身的权利具有内在的兴趣,并且修订控制比分支和标记源控制更为线性的审计跟踪。