subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <>
Subject Re: MTime resurrected
Date Fri, 17 Feb 2012 12:21:00 GMT
"Fuhrmann Stefan (ETAS/ESA1)" <> 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

View raw message