Question

First: I know that SVN does NOT store the actual file timestamp, but only the last commit time.

Second: When checking out files normaly the timestamp of the file is set to the time of the actual check out. This can be influenced by using options like use-commit-times = yes in the subversion config file and Set file dates to the 'last commit time' in Tortoise SVN or use the command svn checkout --config-option config:miscellany:use-commit-times=yes

But I want to actually store the time stamp of the file being checked in AND be able to apply it the the files being check out again!

For source files this isn't a big deal, but we also commit binary third party libraries, for which we realy want to keep the actual file timestamp.

User 'oefe' posted in this thread, that it is possible, but never showed how: https://stackoverflow.com/a/2171973/2339326

Was it helpful?

Solution

With Subversion, you can modify the timestamp of the commit by adjusting the svn:data revision property. This can now be done during the commit itself.

Unfortunately, the basic hooks that could be used are run on the server and not the client. However, Tortoise does provide for client side hooks. You could use one of these to set the commit timestamp to the file timestamp, or (probably better) set a special property with that date.

You have to be careful because this would require all of your users to use TortoiseSVN as their client, and to have these hooks configured on their machine.

Another possibility is not to store these third party libraries in Subversion in the first place. There's a long running argument about whether putting large binaries in Subversion is even a good idea. You don't say what these third part libraries are. If you're a Java development shop, these are third party jars. In that case use Maven or add in Ivy into your current build system, and use a jar repository like Nexus or Artifactory to store these jars.

If this is a .NET environment, take a look at NuGet. If this is a C++ build, you could store the libraries on a release server, and as part of the build process, have the repository download the jars to your working directory. Some places have even used Maven for this part of the build.

You must be careful with timestamps in a build process. The timestamps are used to let the build know whether a particular part of the build needs to be updated. Playing around with the timestamps could cause the build not to rebuild a component that requires rebuilding.

OTHER TIPS

oefe's answer is correct. The only way you can do this is to store the timestamp as a property of each versioned item. To get the full behaviour you're looking for, you would need to write your own client to handle setting/updating the property and fiddling with the local filesystem timestamps. Or write a wrapper around the SVN client to do the same.

But then you also have to ensure that everyone using your repository uses this customized client/wrapper.

For custom 3^rd party binaries, the timestamp should be less important than the version number of those libraries as published by the 3^rd party for the overwhelming majority of workflows.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top