Hello Ed!
Ed <e...@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
