Hello Ed!
Ed <ed_at_kdtc.net> wrote:
> Is my spec similar to yours? With Bert's comments in mind, the
> current spec should be changed to reflect that if the mtime property
> doesn't exist then svn shouldn't even bother with adding it.
Well, a few rounds of discussion more and we'll end up with my
implementation, I think ;-)
> It
> only adds mtime properties to newly imported/added files.
My implementation does that via the auto-props.
That way you can eg. say that only "*.dll", "*.exe" and "*.doc" should
get the mtime property.
>> Sorry, I meant *exactly* that it's (AFAIR) not implemented. It
>> makes a lot of sense, but I fear that the branch will just "apply"
>> the newly fetched R'(x).
>
> It brings me to thinking would the operating system permit svn to update
> the mtime M(x) = R'(x) if the user is still editing the file? Would
> there be an access denied error?
Depends on the OS and editor, I think ...
But if the user is actively working on the file, subversion does an
update, but the editor doesn't notice that and just overwrites the
file - then worse things happen than a lost mtime.
>>> 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?).
>> No, "text" means "data" here, as opposed to "ctime" for "inode time".
>> In the WC library there was the data often named "text", that's
>> where it comes from.
>>
>> (I'd hope that this name doesn't hurt ... and nowadays it's used in
>> at least 3 programs [svntar, fsvs, and svn+branch], so it probably
>> shouldn't be changed now).
>
> Does svntar, fsvs and svn+branch use the text-time property as if it is
> the mtime property? I'm not familiar with svntar, fsvs and svn+branch.
Well, "svn+branch" means my implementation on the branch(es).
And FSVS (http://fsvs.tigris.org) and svntar
(http://svn.borg.ch/svntar/) both use that value as mtime, yes.
(After all, both were meant to be compatible with the meta-data
storage in the subversion branches).
> 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?
Maybe. The actual diff of my implementation wasn't that big, the
update patch in the issue is 273 lines.
But the changes were spread all over the code - partly because
libsvn_wc was a bit of a mess.
With 1.7 that might be much better.
In fact, I believe for 1.7 that will have to be rewritten.
> 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. :)).
I don't know.
A normal text file saves the character at the start, and can easily be
applied, too.
Regards,
Phil
Received on 2010-02-06 17:21:37 CET