"Fuhrmann Stefan (ETAS/ESA1)" <Stefan.Fuhrmann_at_etas.com> writes:
> But since we already have an (optional) feature
> that will use "older" timestamps, I don't see why
> optionally preserving mtime would be too hard.
> The only potential problems that came to my mind
> were sync'ing the wc.db with mtime upon commit
> and clock / timezone issues.
>
> I'm not championing the mtime feature but if
> someone demonstrates a compelling use-case, it
> should neither be hard nor risky to implement it.
The old mtime branch had a fairly basic implementation that had a number
of issues. I've raised these in old threads, but to save time the main
ones I recall were:
- mtime only changes. The old branch treated a file with only an mtime
change as unmodified: it did not show up in status or diff and did not
get committed. That was convenient from an implementation point of
view, but hard to justify otherwise. I think mtime only changes
should be treated as modifications.
- filesystem resolution. The WC filesystem may not be capable of
representing the stored mtime exactly and when this happens it is
likely it should not be treated as a modification. The WC may need to
store two times: the repository time, and the WC time that is
"nearest" the repository time. The old branch ignored this problem
because it ignored mtime only changes.
- merge conflicts. The property will often conflict on merge, some
automatic resolution is probably required. I think the old branch
ignored this problem.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-02-17 13:21:41 CET