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

RE: [RFC] MTime functional specifications (v2.0)

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Sun, 07 Feb 2010 00:38:20 +0000

> > Ed wrote:
> > > Btw, regarding the RFC I submitted. Was I supposed to send it as
> > > a diff, or a text file? (I realize it is a moot point right now,
> > > but for future reference, I think it would be nice to get this
> > > clarified. :)).

As we don't have a base version in the repository yet, for any updates I
would prefer you to send both the diff and the new full text.

Bert Huijben wrote:
> Geoff Rowell wrote:
> > Due to the potentially ubiquitous nature of this property, some
> > consideration needs to be given to when and where the mtime property
> > modification is reported for the affected files and folders.
> >
> > Sometime? Always? Never?
> With the current ra layer the answer would probably be: Always.

I don't think the question wanted a simple answer. The point is that the
design of this feature must consider whether it would often cause
"noise" by causing mtime changes to be reported when they are not

There are two sides to this. First on the repository side: if the design
would often cause mtime property changes to be committed on files that
have not otherwise changed, then, because of the fact that the current
RA layer reporting mechanisms would just report "this file has changed",
that would be bad. That needs to be considered especially after updates
and reverts, I should think.

The other half of the issue is when svn is reporting local WC changes in
a simple "svn status" or "svn diff" command: how does the design ensure
that only useful changes are reported here?

- Julian

Received on 2010-02-07 01:39:02 CET

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