0

Yesterday, a colleague asked me how to configure our VCS to timestamp the local copy of files pulled from the repository with the modification time in the repository. I've always believed that they should be timestamped with the time they were pulled so that if you make a change, build, then back out by overwriting the changed file with the repository's copy, everything that depends on that file will build correctly.

I thought about it overnight, but couldn't come up with a good reason to have timestamped with the repository modification time. What would be the advantages of doing it that way?

(Bonus question: repository modification time and local modification time are the only timestamping strategies that I'm aware of. Are there others in use by VCS systems?)

Niall C.
  • 879
  • 2
  • 11
  • 16

2 Answers2

2

See the tools in the contexts for which they were built. Version control systems are primarily made to track content of source files. They usually only track very little file metadata (executable bit, usually), because you don't need that for managing source code. The timestamp of the file on disk needs to be changed whenever the file is actually changed on your local disk so that your local build tools behave correctly. If you say you need to timestamp to be able to tell which file is which, well, the version control system is there to tell which file is which by means of the all the versions it controls.

If what you actually need is not a source code management tool but a deployment or backup tool, then you should use a tool made for that. All the tools is that area, such as tar, rsync, rpm, dpkg, preserve file modification timestamps and other metadata, because that is necessary or desirable for their job.

Peter Eisentraut
  • 941
  • 5
  • 5
1

Broadly speaking, if you use the repository timestamp then everything is consistent across multiple machines if you use the pull time you haven't got a clue.

Further, if you use the commit timestamp you can see, just by looking at the file, when it was last modified whereas if you use the pull time... well all you know is the last pull time.

This becomes particularly fun if, for example, you're trying to work out if file on a website is right and which files (when its a small number from a bit site) need to be updated.

Now that I've calmed down a teeny bit I do actually understand what you mean about the build issues but pragmatically its easy enough to force a complete rebuild (or it should be) but once you lose a timestamp you can't get it back.

Put bluntly, I've had a lot of pain doing it your way and avoided a lot doing it the other way (though that may in turn be a reflection of the dev tools and deployment issues I have)

Murph
  • 7,813
  • 1
  • 28
  • 41