> -----Original Message-----
> From: Geoff Rowell [mailto:geoff.rowell_at_gmail.com]
> Sent: zaterdag 6 februari 2010 14:26
> To: Ed
> Cc: Philipp Marek; dev_at_subversion.apache.org
> Subject: Re: [RFC] MTime functional specifications (v2.0)
> >
> > I still feel that if this specification goes through RFC and is ok'd,
> > then wouldn't it be easier to take your implementation and modify it
> > to whatever the revised specification states; wouldn't this be a lot
> > easier? While the specification itself is bite sized, I don't think
> > the actual implementation is. (or is it?) Was your solution bite-
> sized?
> >
> > 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. :)).
> >
> 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.
In functions like 'svn status' and 'svn log' we just get the boolean
indicating that one or more properties are changed. Providing more
information would require extensive RA layer changes.
We have some existing issues that indicate that this is a known problem for
'svn:mergeinfo' and you will most likely see only more changes for the
timestamp property. svn log would only indicate that the file was changed..
not if it is a textual change, a property change or a timestamp change.
(If repository and client are 1.7+ you could see if the change is on a
property or textual; but we are not there yet)
I would suggest that if/when we are going to implement a change from this
change-reporting, that we should also look to svn:mergeinfo.
Bert
Received on 2010-02-06 16:01:07 CET