[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: Ph. Marek <philipp.marek_at_emerion.com>
Date: Sun, 7 Feb 2010 11:42:43 +0100

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
Received on 2010-02-07 11:43:23 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.