保留原始时间戳在集市提交/拉/等方面是否有用？

Question

当使用bzr pull时，文件的时间戳变为“立即”(选项1)，而不是将原始时间戳保留在回购(选项2)中。

备选案文1的缺点：

1. 应该是相同的文件变得不同(即使只是在修改时间)。这些差异可能会在拉/提交/等等之间“传播”，它们会污染包中文件的实际修改时间的记录。
2. 使用某些文件(先决条件)的修改时间来评估生成其他文件(目标)的需要的生成系统(如make)可能无法正常工作。在这样的情况下，带有“旧”时间戳的文件被取出，而生成系统忽略了正确的构建(虽然它不应该这样做)，可能表明配置不当的构建过程，或者在make clean之前需要使用make (这应该是用户的责任)。我不认为修改源文件(即使只是它的时间戳)以避免对make clean的需要是方便的。

，如果时间戳是存储库中文件的时间戳，会有用吗？(选项2；类似的问题适用于bzr commit**)** )。

原则上，我会说是的，但应该有一个很好的理由让集市像它那样工作(我只是没有看到它)。

​

编辑：被接受的答案在这里准确地暗示了第2点(我也发布了一个完整的答案)。我以前认为这是一个配置不当的构建系统的症状。但现在我看到，没有办法配置一个构建系统的方式，我认为它应该工作，用现有的工具。使用原始时间戳，将强制每个pull都使用pull，从而重建所有目标。使用"now“作为时间戳，至少可以让系统根据更改的先决条件只重建目标。但我仍然认为这是“损害最小”的选项，而真正的目标应该是两种方式: 1)根据改变的先决条件只重建目标，2)保持跨副本的文件内容的真正修改时间。

​

Answer 1

Bazaar并不是唯一这样的人；据我所知，所有的版本控制系统都是这样工作的。

在这里使用当前时间是正确的，因为构建系统不知道版本控制历史-它只是知道目录时间。在工作树的上下文中，该文件实际上是新文件。

假设有一个构建目标依赖于一个源文件B，该源文件被签入Bazaar，时间线如下：

• T0:在第1版修改后，用户X签出A和B。
• T1:用户Y在集市中更改为B
• T2:用户X构建一个从B派生的构建目标(例如编译它)
• T3:用户X引入用户Y的新版本，B的时间戳更改为T1 (比构建目标的T2更早)
• T4:用户X再次尝试构建，但是B的时间戳比构建工件古老，因此没有重建任何东西

Answer 2

现在使用而不是记录的时间有一个简单的原因:构建系统(如make)可以简单地发现文件被更改，并根据该文件重新构建工件。

Answer 3

理想情况下，在使用版本控制 (VC)时，使用像bazaar (版本控制系统)这样的软件时，可以：

1. 保持文件内容跨各种副本的真实修改时间，因为这是有关文件的重要信息。不管VC下文件的具体内容如何，这都是正确的。
2. 确保根据VC下更改的先决条件构建目标，并在获得修改副本(例如bzr pull)后进行重建。这一点很重要，因为VCS的典型使用是:软件开发。引用维基百科的话： 有必要有一种逻辑的方法来组织和控制修订已经存在了几乎只要书面已经存在.今天，最有能力(也是最复杂)的修订控制系统是那些在软件开发中使用的，.
3. 确保不依赖于VC下更改的先决条件的构建目标，在获得修改副本后不会重新生成。这避免了处理时间上可能存在的重大负担。(我看不出放弃这一点还有什么坏处)。

使用bzr (以及其他VCS?)以目前的形式，一个人不能得到这三个。

可以使用原始时间戳获得(1+2)，并对每个pull执行make clean (或类似的操作)，从而重建所有目标，而不仅仅是少数目标。另一方面，可以使用"now“作为时间戳(2+3)。(1+3)既不可能，也不有趣。

bzr (和所有其他VCS？)，考虑到软件开发，让(2+3)占上风，放弃点1。

那么，会有用吗.？

是的，但可能不足以对付其他方便点。

请参阅保存原始时间戳的版本控制系统？

PS:这总结了其他答案，特别是我的编辑OP的，使之成为对特定问题的答案。