Is keeping original timestamp useful in bazaar com

Question

When using bzr pull, the timestamp of files becomes "now" (option 1), as opposed to keeping the original timestamp in the repo (option 2).

Cons of option 1:

1. Files which should be the same become different (even if only in the modification time). These differences may "propagate" across pulls/commits/etc. and they would contaminate the record of actual modification times of files in a package.

2. Build systems (like make), which use the modification time of some files (prerequisites) to evaluate the need for making other files (targets), may not work properly. A case where a file with an "old" timestamp is pulled and the build system ignores that for a correct build while it shouldn't, probably indicates an ill-configured build procedure, or the need for make clean prior to make (and this should be the responsibility of the user). I do not see any case where altering a source file (even if only its timestamp) to avoid the need for make clean is convenient.

Would it be any useful that the timestamp is that of the file in the repository? (option 2; a similar question goes for bzr commit)

In principle, I would say YES, but there should be a good reason for bazaar to work as it does (I only do not see it).

---

EDIT: The accepted answer alludes exactly to point 2 here (I have posted a thorough answer as well). I had previously seen this as a symptom of an ill-configured build system. But now I see there is no way of configuring a build system for the way I think it should work, with current tools. Using the original timestamp, one would be forced to make clean with every pull, thus rebuilding all targets. Using "now" as the timestamp at least lets the system rebuild only the targets depending on changed prerequisites. But I still see this as the "least damaging" option, while the true objective should be having it both ways: 1) rebuilding only the targets depending on changed prerequisites, 2) keeping the true modification time of files contents across copies.

Answer 1

Ideally, when using Version control (VC), with software like bazaar (Version control system, VCS), one would be able to:

1. Keep the true modification time of files contents across the various copies, since this is an important piece of information about a file. This is true regardless of the specific contents of the files under VC.
2. Make sure that build targets depending on changed prerequisites which are under VC, are rebuilt upon obtaining modified copies (e.g., bzr pull). This is important due to the typical use of VCSs: software development. Quoting from Wikipedia:
   

   The need for a logical way to organize and control revisions has existed for almost as long as writing has existed... Today, the most capable (as well as complex) revision control systems are those used in software development, ...

3. Make sure that build targets not depending on changed prerequisites which are under VC, are not rebuilt upon obtaining modified copies. This avoids possibly significant overburden in processing time. (I see no other downside to forgoing this point).

With bzr (and any other VCS?) in its present form, one cannot get the three.

One could get (1+2) using the original timestamp, and doing make clean (or the like) with every pull, thus rebuilding all targets instead of only a few. On the other hand, one could get (2+3) using "now" as the timestamp. (1+3) is neither possible or interesting.

bzr (and all other VCSs?), with software development in mind, let (2+3) prevail, forgoing point 1.

So, Would it be any useful...?
Yes, but perhaps not enough to counter other convenience points.

See Version Control System that keeps original timestamps?

PS: This summarizes other answers, and in particular my EDIT of the OP, into an answer to the specific question.

Answer 2

There is a simple reason to use now instead of the recorded time: a build system (like make) can simply find out that the file is changed and rebuild artifacts depending on that file.

Answer 3

Bazaar isn't alone in behaving like this; all version control systems work like this as far as I know.

Using the current time is correct here, because the build system is not aware of version control history - it's just aware of the directory times. In the context of the working tree, that file is actually new.

Imagine the situation where there is a build target that depends on a source file B that is checked into Bazaar with a timeline like this:

• T0: User X checks out A and B after at revision 1.
• T1: User Y makes a change to B in Bazaar
• T2: User X builds a build target that is derived from B (e.g. compiling it)
• T3: User X pulls in the new revision made by user Y, the timestamp of B changes to T1 (so earlier than the T2 of the build target)
• T4: User X attempts to build again, but the timestamp for B is older than the build artifact and thus nothing is rebuilt