[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: MTime resurrected

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 17 Feb 2012 12:21:00 +0000

"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

This is an archived mail posted to the Subversion Dev mailing list.