Hello Julian!
> 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
interesting.
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.
In my branch that would be a non-issue.
As the property would be changed on a commit, only files that get
committed (ie. that are really changed, or at least have other
property changes) would have a changed svn:text-time.
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?
The same happens locally - the changed svn:text-time is simply not
seen, because it's just a property that gets sent along to the server.
Of course, that means that a mtime-only change (think "touch") cannot
easily be committed.
Regards,
Phil
