我们是否对"派生"文件进行版本控制?
使用在线与版本控制系统的界面是为最新版本的代码提供已发布位置的一种好方法。例如,我在这里有一个LaTeX软件包(每当验证更改可以正常工作时,该软件包就会发布给CTAN):
http://github.com/wspr/pstool/tree/master
软件包本身是从一个文件(在本例中为pstool.tex)派生的,该文件在处理时会生成文档,自述文件,安装程序文件以及构成LaTeX使用的软件包的实际文件。
为了使想要下载此内容的用户更容易,我在存储库中包括了上述所有派生文件以及主文件pstool.tex。这意味着我每次提交的更改次数都会增加一倍,因为包文件pstool.sty是主文件的生成子集。
这是版本控制的变态吗?
@Jon Limjap提出了一个很好的观点:
Is there another way for you to publish your generated files elsewhere for download, instead of relying on your version control to be your download server?
在这种情况下,这确实是问题的症结所在。是的,可以从其他地方获得该软件包的发行版本。因此,仅对未生成的文件进行版本化确实更有意义。
另一方面,@ Madir的评论是:
the convenience, which is real and repeated, outweighs cost, which is borne behind the scenes
这也很相关,因为如果用户发现错误并立即修复,则他们可以转到存储库并获取继续工作所需的文件,而不必执行任何"安装"步骤。
我认为,这对于我的特定项目集来说是更重要的用例。
解决方案
回答
不一定,尽管出于明显的原因,尽管源代码控制的最佳做法建议我们不要包括生成的文件。
我们是否还有另一种方法可以将生成的文件发布到其他位置进行下载,而不是依靠版本控制作为下载服务器?
回答
通常,派生文件不应存储在版本控制中。在情况下,我们可以构建一个释放过程,以创建一个包含衍生文件的tarball。
如我们所说,将派生文件保留在版本控制中只会增加我们必须处理的噪音。
回答
我们不对可使用存储库本身中包含的脚本自动生成的文件进行版本控制。这样做的原因是,在签出后,可以通过单击或者命令来重建这些文件。在我们的项目中,我们始终尝试使此操作尽可能容易,从而避免对这些文件进行版本控制。
我可以想象一种情况,如果"标记"产品的特定发行版,以供生产环境(或者任何非开发环境)使用,在该环境中可能无法使用生成输出的工具,那么在哪种情况下该方法很有用。
我们还在构建脚本中使用目标,这些目标可以使用我们产品的发行版来创建和上传档案。可以将其上载到生产服务器或者HTTP服务器,以供产品用户下载。
回答
我正在使用Tortoise SVN进行小型系统ASP.NET开发。大多数代码都是使用ASPX解释的,但是手动编译步骤会生成大约十二个二进制DLL。从理论上讲,对这些源代码进行版本化没有多大意义,但无疑可以方便地确保将它们正确地从开发环境镜像到生产系统(单击一次)。同样,在发生灾难的情况下,回滚到上一步也是在SVN中单击一次。
因此,我忍无可忍,将它们包括在SVN存档中,这种便利性是真实而又重复的,其价值超过了幕后承担的成本。
回答
在某些情况下,我们可以这样做,但更多是sysadmin类型的用例,在这种情况下,生成的文件(例如,通过脚本构建的DNS区域文件)本身具有内在的利益,而修订控制则比线性审核跟踪更具线性。分支和标记源控制。