Question

I’ve got a large source tree (> 2 GB, WINCE build tree) that I would like to start managing with Subversion. Up to this point, ‘versioning’ has been managed through keeping multiple copies of the tree, and using Beyond Compare to find differences.

The last big stumbling block I see to using Subversion is that it modifies the file timestamp to be the commit time. This makes Beyond Compare comparisons much more time consuming, because you must do a binary compare to find changes.

I’ve looked at the meta-data versioning branch of the subversion source tree, but I would prefer to not try to merge that code from 2006 into the current svn source.

Thanks,

Dave

Answer 1

There is an svn config option that controls how timestamps are stored in the repository:

use-commit-times 

Normally your working copy files have timestamps that reflect the last time they were touched by any process, whether that be your own editor or by some svn subcommand. This is generally convenient for people developing software, because build systems often look at timestamps as a way of deciding which files need to be recompiled.

In other situations, however, it’s sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. The svn export command always places these “last-commit timestamps” on trees that it produces. By setting this config variable to yes, the svn checkout, svn update, svn switch, and svn revert commands will also set last-commit timestamps on files that they touch.

See Runtime Configuration Area and Configuration Options

BTW, Beyond Compare rocks! I use all of the ones mentioned, svn diff, TortoiseMerge and BC2. BC2 is the most complete.