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