[re depending on mtime in Subversion]
> I think of it in a broader, more general way. And I keep saying that
> Subversion can't on one side say that mtime is unreliable, useless,
> worthless, and then on the other side takes the awful chance of
> making its first and vital decision on just that. And it is one thing
> not to commit changed files with unchanged mtime, but quite
> another to overwrite such files on update, even if the filesize has
> changed. A plain, general purpose file synchronizer like Total
> Commander at least takes two parameters into consideration.
> That still leaves a chance. Someone said that rsync and tar
> handle this since long, and rsync still is said to be extremely fast.
>
> A tool that puts so much aim in claiming to protect any bit of user
> data like Subversion does should at least not fall behind tools with
> a lesser claim in this field. That's the whole point of it.
Yesterday I realised that I had an unfinished change in one of my
working copies which - when appropriately adjusted - could give us
what you want quickly: extend the 'changedness'-heuristic with the
factor 'file size'.
Since this isn't the first time it has come up in the past weeks
(months), I decided to adapt that unfinished change. I committed it
this morning as r23767. This means it will be available in 1.5. If you
want, you can try backporting it to 1.4. We won't, because it changes
the public interface.
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Mar 10 14:02:08 2007