71

I want to be sure that if I commit something in Subversion from one machine, and I checkout on another, I will get the same value for datetime and timestamp.

Currently, I observed that the datetime of file's modification is from the moment when I did the synchronisation instead of the original value.

For me, it doesn't make any sense to know when the files were synchronised - I just want to see the last commit time.

This issue is not timezone related.

sage
  • 4,863
  • 2
  • 44
  • 47
sorin
  • 161,544
  • 178
  • 535
  • 806
  • I second this -- if it's not possible, maybe it should be a feature request. – Nick Bolton Jan 31 '10 at 14:10
  • 6
    Use case: you have a product (source) that is modified by your team and each time the product is updated you need to resync your changes. If the files timestamps are altered the file comparison will not work, or it will be much much slower. Some problem occurs if you want to sync two different checkouts that do have local modifications, modifications that will never go upstream. – sorin Jun 13 '12 at 09:15
  • 1
    The real life use case: take lrzsz-0.12.20.tar.gz, unpack it and import to your SVN (to a vendor branch for example). Then try to configure and build the copy checked out from SVN and the copy unpacked from the tarball. There is a high chance that building the SVN version will fail because make will want to rebuild Makefile.in because timestamp of aclocal.m4 is newer than that of Makefile.in. Just because svn checked out aclocal.m4 after Makefile.in. I currently have to touch Makefile.in from an upper level Makefile to make things work for me. That's weird. – Alexander Amelkin Aug 31 '12 at 16:00
  • 1
    Possible duplicate of *[Getting TortoiseSVN to set a file's modified time to the timestamp of the latest revision](http://stackoverflow.com/questions/945200/getting-tortoisesvn-to-set-a-files-modified-time-to-the-timestamp-of-the-latest)*. – Peter Mortensen Apr 02 '14 at 12:25
  • Third use case: you're given the task of cleaning cruft out of a tree and you don't want to interact with the log every time you want to find out how long since something has been touched. With this, `find path -mtime +365` works like a charm - just don't forget to unbreak svn after you're done! – sage Apr 03 '15 at 15:01

4 Answers4

69

You can set it in .subversion/config:

[miscellany]
use-commit-times = yes

Although you will have strange side effects if we are talking about source files.

For example, you build your software and do svn update. Now the timestamp of the updated files is older than the timestamp of the build result file, and it won't be rebuilt even though some source files changed. Be very careful with this setting.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
silk
  • 2,714
  • 22
  • 21
  • 12
    This sets the modification time of the checked out copy to be equal to the time when changes to it were last committed to the repository. This is *not* the same as preserving the modification date the file had when it was originally imported into the repository. – bendin Jan 31 '10 at 19:26
  • 5
    I believe it is what OP meant - as stated in the question - "I just want to see the last commit time." – silk Jan 31 '10 at 20:40
  • Seems that the obvious solution is not implemented: what I would want is transferring the modification time (not commit or checkout time) and when merging while checkout the newer time is used. – Jochen Sep 03 '12 at 20:38
  • 13
    To preserve times on checkout the following command can be used: `svn checkout --config-option config:miscellany:use-commit-times=yes ` – Onlyjob Jun 07 '13 at 01:44
  • 6
    Be aware that `use-commit-times=yes` still doesn't help with directory modification times. Those will be set to `now`. – valid Mar 14 '14 at 11:05
34

If you are using TortoiseSVN, there is an option. TortoiseSVN -> Settings -> General -> "Set file dates to the 'last commit time'".

Right click on your Tortoise shortcut to settings

Jenna Leaf
  • 2,255
  • 21
  • 29
nickf
  • 537,072
  • 198
  • 649
  • 721
  • 7
    THis isn't the original timestamp. – oefe Jan 31 '10 at 14:15
  • 1
    This option sounds like a good solution but how can I control this when I use command line svn client (like SlickSVN and not TortoiseSVN )? A cross platform solution would be better. – sorin Jan 31 '10 at 14:46
  • 1
    The OP states: "For me, it doesn't make any sense to know when the files were synchronised - I just want to see the **last commit time**." – Lee Taylor Sep 27 '14 at 16:22
  • Yes, this works most of the time. However, on a shared drive, in a Windows installation inside VirtualBox I experienced that SVN/Subversion ignored this setting. But it worked as expected on that same Windows installation on its drive "`C:`". – Peter Mortensen Oct 24 '17 at 16:37
14

Subversion doesn't preserve the original timestamp of the file.

If you absolutely need to preserve the timestamp, you have to do it yourself. For example, you could store the original timestamp as a Subversion property.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
oefe
  • 19,298
  • 7
  • 47
  • 66
  • That's not true, you can enforce this with a config setting, you don't have to do it yourself. – silk Jan 31 '10 at 14:39
  • 9
    Againg, no- use-commit-times = yes is the time the file was committed, not the original timestamp. – oefe Jan 31 '10 at 14:50
  • Ahh, ok, I misunderstood you, sorry. – silk Jan 31 '10 at 15:20
  • 2
    Note: This question faithfully answered the original question's title before clarification/edit (which is pending peer review at time of comment). @oefe is right that Subversion does not store original *modification* timestamp, only the *commit* timestamp. – sage Apr 03 '15 at 15:05
2

It would seem 'stat -c %y $FILE' be used as part of a pre-revprop-change hook that operates on svn:date. Only issue I might see is the date format.

ImpressTheNet Web Developer
  • 377
  • 2
  • 2