Philip Martin <philip.martin_at_wandisco.com> writes:
> We have a new flag and a new mode, so the new behaviour can be almost
> anything. Why is is acceptable to ignore mtime-only changes? It makes
> no sense to me. It might be acceptable as an experiment but really it's
> a half-baked solution.
Perhaps that came across as too harsh; I don't want to put you off
working on this. I've never needed mtime versioning but other people
do want it.
The old branch started with a very simple idea: save the mtime at commit
and optionally restore it at checkout/update. It's relatively simple to
implement. The problem I have with this branch is that a lot of the
resulting behaviour is just whatever happened to fall out from that
particular implementation. So, touch a file to change the mtime and the
file doesn't show up in status and cannot be committed. Set a property
as well and the file can be commited and the commit will include the
mtime change. That inconsistency worries me.
It's not a difficult problem to fix, but changing it leads to the
resolution problem. The resolution problem probably isn't that hard
either, when we store last-mod-time in NODES we know the file is
unmodified so it may be just a question of realising that last-mod-time
may not be same as repository-mtime.
One way to progress is to get some sort of consesus about the behaviour,
but so far this hasn't happened. In the past when people ask questions
about the behaviour the discussion just tends to die away. The other
way to progress is to decide that you know how it should behave, write
some code, and show the rest of us that it works.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-17 21:29:55 CET