Which VCS is capable of preserving file timestamps?_问答_开发者

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 timestam开发者_如何学Pythonps 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

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:

Download and install the extension.
Initialize the repository where you want to preserve timestamps, add the files, but don't commit yet.
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
```
Do the initial commit to store the files in the repository with their proper timestamps.

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)

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.

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.

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

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.

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.

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.