"Fuhrmann Stefan (ETAS/ESA1)" <stefan.fuhrm...@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
