Which VCS is capable of preserving file timestamps?

Question

I have a collection of files that represent a "project" (txt, cfg, hand edited binary, scripts, etc) that I would like managed in a repository. I would like to house the repository and server (if necessary) on my home Windows machine and be able to access it remotely and locally.

I have setup VisualSVN server and TortiseSVN client and it all works perfectly except for one major hangup; file timestamps. When I add a file to the repository, SVN wipes out the last modified date and changes it to the date when it was committed.

I have files that have dates that span the last 4 years and keeping these timestamps is important to me. I have searched, but have not found a solution to this problem (even though it seems plenty of other people have asked for the same behavior).

So my question is, is there a FREE VCS that allows for original file timestamps to be captured and meets my other general use criteria? I glanced at GIT, but it didn't seem like it did, and I wasn't sure about CVS.

Thanks for any and all help,

Rob

Marcelinomarcell

I don't know of any, but could if this information is important, can you capture it and record that information in separate file under source control? – Evonneevonymus

Do you want the timestamps of the file to be re-created when you check out the repository again? – Alli

By "swiping", you mean the "real" last modified date is obliterated in SVN for the one established by SVN when it was added to the repository? – Blinker

It makes more sense if you think about creating a new repository for a collection of pre-existing files. If you have files from 2006, and you create an SVN repository today, once you add them to the repository the real modified date is lost. Upon checkout they will will have today's timestamp. Now, if I had created my repository first, and added the files as they were created, there wouldn't be a problem. – Marcelinomarcell

This really shouldn’t ever be necessary. You can always look at the version history for the file in the VCS to see when it was last changed. – Cleromancy

Answer 1

I FIGURED OUT A WORKAROUND

Thank you all for your input. I have figured out a workaround that allows me to continue using my current SVN setup. I simply archive the pre-existing files and folders that I wish to retain original dates. The archive itself has the date changed to current on the first commit, but the files in the archive when expanded keep their original dates. Then when/if they are updated, I delete them from archive and add them directly to the repository.

It's kind of hokey, but it works for me. I think it would be nice if SVN could auto capture the timestamp in a property and have an option in the client to grab it and modify the timestamp on checkout. Obviously it wouldn't be default behavior, but I don't see any harm in having that option.

Marcelinomarcell

Answer 2

There is an extension to Mercurial that automatically saves file timestamps. I have tried it out and it seems to work well. In order to get it to work properly, you must do the following:

1. Download and install the extension.

2. Initialize the repository where you want to preserve timestamps, add the files, but don't commit yet.

3. Generate the timestamps file. I think you have to do this before you commit the file, but I haven't tried it both ways to be sure.

   hg timestamp_mod -s
   

4. Do the initial commit to store the files in the repository with their proper timestamps.

Belford

Answer 3

Truly preserving the timestamp of each and every file is not an approach that scales well.
I should know, the one CVCS (Centralized VCS) which does this is... ClearCase! (see the checkin -ptime option)
And it is sloooooow :)
Plus, as manojlds mentions, there is this thread against this idea for Git.

Still, there was a study, for SVN, for preserving timestamps:
Building with a Version Control Audit Trail from Alec Clews, with an example in github/svnbuilding.
And there was a similar study with github/gitbuilding.
In both case, it is about recording the information in a separate file, and even that wasn't about restoring dates and time...

So if you need this information:

a/ it better be for all the files you are putting in a VCS (especially a free one, or any DVCS)
b/ you could, with Git:

• make your commit
• then, for the relevant files, add the timestamps information with git notes (which is able to add any kind of metadata you want on top of any commit, without changing the SHA1s)

Enthrall

Answer 4

This probably won't help, but RCS does this.

When checking in a file, ci -d sets the check-in date and time to the working file's time of last modification.

When checking out a file, co -M sets the modification time on the new working file to be the date of the retrieved revision. NOTE: The co(1) man page says

Use this option with care; it can confuse make(1).

Of course RCS probably lacks a lot of other features you're going to need, like remote access.

Melodie

Thank you for this. RCS still solves so many use-cases for me. It is still an excellent tool, and in some cases no DCVS can substitute it. – Mckie

Answer 5

This would be a bad idea for a VCS, there may be some valid use cases for some - but they'll be really obscure and not software related. All VCS systems keep track of this metadata, and your build script could query it and then backdate your files.

Out of curiosity, why would you want to do such a thing? I think expounding on the problem you have and asking for a solution will yield you better results than asking how to implement the one solution you've seized on.

Pitiful

The date a file was modified is often very useful information. Seeing what files have been touched recently is particularly useful when skimming a directory. If the VCS blows away this context, a lot of filesystem tools become much less useful. – Detwiler

But the VCS doesn’t blow away this context: it’s in the file’s history that’s stored by the VCS. Just look at the version log for the file. – Cleromancy

Answer 6

I am not sure if this what you want, but the following uses the commit time. If you want the timestamp to be preserved when first committing, I don't see a way, except maybe adding it in a svn property.

You can add this to your svn config and it should use commit time:

[miscellany]
use-commit-times = yes

It can cause some problems / confusion when timestamp changes to older date so use it knowing what the consequences are.

This is the same or worse in DVCSs like Git. Linus reply in a thread on timestamp:

I'm sorry. If you don't see how it's WRONG to seta datestamp back to something that will make a simple "make" miscompile your source tree, I don't know what defintiion of "wrong" you are talking about. It's WRONG. It's STUPID. And it's totally INFEASIBLE to implement.

http://kerneltrap.org/mailarchive/git/2007/3/1/240167

Jurassic

Yes I have seen this answer before. Unfortunately it is not what I am looking for. I need a way to preserve the timestamp for the initial check-in of a file. Meaning, if I want to add a file to the repository that was last modified in 2006, I want to make sure when I check it out (typically as a whole subdirectory) I want it to still say 2006. I can understand the perspective that this would cause problems for a software project using Make, however I would argue that single executable software projects are not the only use case for a VCS. – Marcelinomarcell

Answer 7

CVS can do it. You have to add files initially with cvs import -d ... After that the initial checkout will create files with the original timestamp. Subsequent updates of any kind will change the timestamp in the working copy to the current time such as to not confuse make or similar tools. Only the initial checkout will get you the original time. I like that behavior a lot as it allows you to record history accurately.

I am currently looking myself how to do this with git but it seems it doesn't.

Tiberius

Answer 8

This works in TortoiseSVN to preserve the original timestamps. After creating a new project and after first checkout a) Use a tool like TotalCommander to set/correct the timestamps manually or better b) Just copy / replace all files from the originally location with original timestamps to the working copy of your TortoiseSVN checkout. Replace all files. Now they have the original timestamp again. TortoiseSVN detects that the files haven't changed and leave them alone.

Attention: Only works for personal / single user use-case. If you check out the files, TortoiseSVN will use commit or current timestamp again. But as long you only use SVN to checkin in single user usecase, it will be fine.

Chagrin