Preserve file modified date in commit

[chli...@gmail.com]

Hi,

I'm trying to preserve the original modification date for files being added into SVN, rather than the add/check-in date or the check-out date.

Currently I'm doing this through a very slow and painful method: Iterate through files, commit one at a time, revprop change after the commit to set the revision date to the file's modified date. This produces THOUSANDS of tiny revisions, which makes working with the repo harder (ie, can't check out a random revision as it might be broken/incomplete, admin operations are much slower than they should be, etc). Is there a better way to do this using custom properties and either server side or client side scripts?

I'm not just a masochist... my application is extremely sensitive to file dates.

Thanks,
Joe

[Stefan]

On Tuesday, July 9, 2019 at 7:37:16 PM UTC+2, Joe Chlimoun wrote:

Hi,

I'm trying to preserve the original modification date for files being added into SVN, rather than the add/check-in date or the check-out date.

you know that "modification date" is not the same as "commit date"?

 

Currently I'm doing this through a very slow and painful method: Iterate through files, commit one at a time, revprop change after the commit to set the revision date to the file's modified date. This produces THOUSANDS of tiny revisions, which makes working with the repo harder (ie, can't check out a random revision as it might be broken/incomplete, admin operations are much slower than they should be, etc). Is there a better way to do this using custom properties and either server side or client side scripts?

I'm not just a masochist... my application is extremely sensitive to file dates.

What you're doing is basically rewriting history. And that's bad.

You're changing the commit date (that's what that date in svn is, not a file modification date). Which means you can (and will) get situations where a commit has files with commit dates that are after commit dates from a future commit. Meaning the revision numbers increasing won't mean that file dates also are increasing. -> that can work for a while, but will definitely break some svn commands because that's now allowed to happen.

[dongl...@gmail.com]

As far as I can tell, revision date is an unnecessary thing, what matters is revision sequence... I haven't yet found anything that cares if dates are out of sequence, it seems to be just useless metadata.

But, for what it's worth, I moved away from this method. Now I'm using a custom property on each file, which I can set in my working copy with a local pre-commit and restore with a local post-update. It's so much faster, but it is kind of a pain because now everyone using the repository needs to have the scripts (whereas previously the script was only needed on commit, people exporting didn't need it as the client just used the revision date). Still, this method is somewhat cleaner since it doesn't generate one revision per file.

I thought about just modding svn to gracefully handle file mod dates, like other revision control systems can be configured to do, but it could be awhile before that makes it into the release version, and I don't want to run something home-rolled at work that I'm stuck maintaining. If I had a choice, I'd join the modern world and not care about file mod dates, but my toolchain is ancient, by necessity.