views:

1017

answers:

3

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

A: 

Subversion will do the comparsion much quicker than even beyond compare will do..

If you use tortoiseSVN you even can use beyond compare as external Diff tool.

Peter Parker
It was a problem with the user, not with the system not doing what it should. Thanks for the quick response.
DavidEBest
A: 

After a quick check: If you commit a file from your working copy, it keeps it's timestamp (last modification time). Even after an update (without further remote changes to this file) the file keeps the timestamp of the last modification. The test was on Linux with Subversion version 1.4.6.

If you update a file, that was changed remotely it gets a new timestamp.

So you keep timestamps of last modification.

Besides: Why you want to use 'Beyond Compare' for diffs. You will no longer need to keep different directories to reflect different versions. And subversion has a diff-feature of it's own to prepare diffs for combinations of revisions.

Mnementh
It was a problem with the user, not with the system not doing what it should. Thanks for the quick response.
DavidEBest
+1  A: 

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.

Ken Gentle