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. -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/4ab14f0c-d9ea-4111-8b16-e46f84a0ef90%40googlegroups.com.
