Hi Philipp,
As usual, thanks for the prompt comments.
>> +Issue #1256 was entered into the Subversion issue tracker on 24th April
>> +2003 and has been opened since then. A few patches have been submitted;
> There's even a branch with a full implementation in the subversion
> repository, and it's been ported to relatively current versions - maybe
> that's what you mean by "patches" here.
All of those patches I was referring to were your patches as included in
the issue 1256 attachment list. Just a cursory query. If there exists
a full implementation of 'mtime', (I really should look at the contents
of the branches more often) this means it's already been implemented.
Is the point of a functional spec to flush out the details of the
implementation? Or should I just follow the implementation and
apply the functional specs according to what is implemented. (Or does
this make any sense? )
>
>> + - Whenever Subversion modifies a file (or directory) in the WC, and
>> + there are local changes to that node, such as when updating a file
>> + that the user has been editing, it shall update the mtime property.
> This isn't implemented in the branch, AFAIR.
I wasn't really sure about this point. I'm assuming that the user
had saved some changes (motto: save often :)), so then the actual
on-disk mtime would change. Then if the user updates his/her WC,
here's where I'm iffy.
If user A edits x with mtime M(x) and repository mtime of R(x), then
user B commits a change to x and commits it then R(x) becomes R'(x).
Then if user A edits his/her WC's x, thus M(x) becomes M'(x) and
then updates his/her WC. Then the system will compare R'(x) and
M'(x). Maybe I'm getting confused, but isn't that in itself
a conflict of properties? (Mind you, this doesn't necessarily mean
a conflict of file content since there are updated non-conflict
situations.) I think if there is a conflict in file content then
the user has a bigger problem to resolve.
t
>
>> + Mtime shall be stored in a versioned property named 'svn:mtime'.
>> + Any file or directory may have this property. The format of the
>> + property value is 'YYYY-MM-DDTHH:MM:SS.UUUUUU' of which the time
>> + is UTC.
> Very fine. And if you change that to "svn:text-time", this is already
> specified in svn_props.h:
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_props.h
If it's already defined in svn_props.h, then it's a lot easier to
use the existing one (would users expect it to be called 'mtime',
since using 'text-time' might mean that it can only be used for
text files as opposed to binary files?).
>
>> + ... This functional specification takes
>> + the tact of setting the 'svn:mtime' property to the current
>> + mtime as it will give the user at least a starting point
>> + to which to make their statistical/informational mtime references.
> So there's no way to have some part of the WC with mtime-storage, and another
> without? I'm thinking about generated binaries that you want to keep.
Pardon me for being a bit dense. Do you mean that generated binaries
(or binaries in general?) should not have the 'mtime' stored?
Thanks,
Edmund
Received on 2010-02-05 09:21:23 CET