当使用bzr pull ，文件的时间戳记“现在”（选项1），而不是保持原有时间戳回购（选项2）。
选项1的缺点：
文件应该是相同变得不同了（即使只在修改时间）。 这些差异可能“传播”跨拉/提交/等。 他们会污染的文件的实际修改时间记录在一个包。
构建系统（如化妆），它使用一些文件（必备条件）的修改时间来评估使其他文件（目标）的需要，可能无法正常工作。 其中有一个“老”时间戳的文件被拉动并构建系统中的情况下忽略了正确的构建，同时它不应该，可能表示生病配置的构建过程，还是需要make clean之前make （这应该是用户的责任）。 我没有看到任何情况下改变一个源文件（即使只是其时间戳），以避免需要make clean方便。
难道是任何有用的时间戳，在库中的文件？ （选项2;一个类似的问题也适用于bzr commit ）
原则上，我会说是的，但应该有一个很好的理由义卖工作，因为它（我只是没有看到它）。
编辑 ：接受的答案正好暗示这里2点（我已经发布了一个完整的答案也一样）。 我以前见过这个作为一个坏配置构建系统的症状。 但现在我看有没有配置构建系统，我认为它应该工作，当前工具的方式的方式。 使用原来的时间戳，一个将被迫
make clean每
pull ，从而重建的所有目标。 用“现在”的时间戳至少可以让系统根据变化的前提条件只有重建的目标。 但我仍然认为这是在“损害最小”的选择，而真正的目标应该是具有这两种方法：1）仅重建目标取决于先决条件改变，2）保持跨越拷贝文件的内容真实修改时间。
巴扎不单单是表现这样; 所有的版本控制系统这样的工作，据我所知。
使用当前的时间是正确的在这里，因为构建系统是不知道的版本控制的历史 - 它只是知道目录倍。 在工作树的背景下，该文件实际上是新的。
试想一下，那里是一个构建目标取决于被检查到集市有这样的时间表源文件B的情况：
- T0：用户X在修订版1后检出A和B。
- T1：用户Y带球巴扎变化到B
- T2：用户X构建是从B来源（例如编译它）构建目标
- T3：用户X在由用户Y，的乙变化T1的时间戳（早于构建目标的T2）进行的新修订拉
- T4：用户X尝试再次建立，但对于B中的时间戳比构建神器旧的，因此没有被重建
有一个简单的道理，现在使用的，而不是记录的时间：构建系统（如MAKE）可以简单地找出该文件被更改和重建取决于文件的文物。
理想的情况是，当使用版本控制 （VC），与像集市 （版本控制系统，VCS）软件，一个将能够：
- 保持跨越各个副本文件的内容真实修改时间，因为这是有关文件的一个重要信息 。 这是无论VC下的文件的具体内容属实。
- 确保建立依赖于改变其先决条件是VC下的目标，是在获得经修改副本（例如，重建
bzr pull ）。 这很重要，因为典型用途VCSS的：软件开发。 从引用维基百科 ：
需要有一个合乎逻辑的方式来组织和控制修改已经存在了几乎只要写作已经存在......今天，最有能力的（以及复杂的）版本控制系统是指那些在软件开发中，...
- 确保不依赖于改变其先决条件是VC下是构建目标，都没有在获得经修改副本重建。 这避免了在处理时间可能显著覆盖层。 （我看不出有什么其他缺点放弃了这一点）。
随着bzr （以及任何其他VCS？）以其目前的形式，不能拿到3。
人们可以得到（1 + 2）使用原来的时间戳，和做make clean （或类似）每pull ，从而重建所有目标，而不是只有少数。 在另一方面，人们可以用“现在”的时间戳得到（2 + 3）。 （1 + 3）既不可能或有趣。
bzr （和所有其他VCSS？），在考虑软件开发，让（2 + 3）为准，放弃1点。
因此， 这将是任何有用的......？
是的，但也许还不足以对抗等便民点。
见，保持原有的时间戳的版本控制系统？
PS：这概括其他的答案，特别是我的OP的编辑 ，到回答的具体问题。
