This question stems from Is keeping original timestamp useful in bazaar commit/pull/etc.? and in particular from this answer.
Ideally, when using Version control (VC), with software like bazaar (Version control system, VCS), one would be able to:
- 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.
- 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, ...
- 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).
Is there any VCS that achieves all three?
With
bzr
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
, with software development in mind, lets (2+3) prevail, forgoing point 1.
This does not answer the specific question (Is there any VCS that achieves all three?) but suggests a way of achieving it.
pull
modified files with "now" as timestamp (asbzr
does), but also pull the information about true modification time of those files and store it.touch
modified files with the known true modification times.This will leave the local copy in ideal conditions. Thus, a piece of software that could operate this way would be a solution. Moreover, actions (2+3) could be encapsulated into an "enhanced build" action.