Philip Martin <philip.mar...@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
