On Montag, 21. Dezember 2009, Branko Čibej wrote:
> Edmund Wong wrote:
> > The patch is attached to this one. Thanks Phlip!
>
> Apparently you're having trouble sending patches, because nothing came
> through again. Do you have an outgoing mail filter, perhaps? I don't
> believe Apache mail servers drop attachments....
Well, in my private mail the patch came through.
So I'll be the first with comments ....
+ property. The format of the property value is 'YYYY-MM-DD HH:MM:SS'
+ of which the time is UTC.
Please make that conform to the meta-data branch, and use the notation
2009-12-11T23:26:08.123131
which includes sub-seconds, too, so that users won't complain that this
information is lost, although their filesystem can store nanoseconds!
(And TBH I think that the relative ordering of file-writes is important in
some cases, too.)
+ o if x = dir, then recurisvely f_import(x)
typing error, multiple times.
commit:
+ 3) R(x) = M(x)
In the other lines you had a "Set", too.
export:
+ 2) Is S(x) == NULL?
+ Yes: Set the current M(x) as the file's
+ mod time.
Why wouldn't you use R(x)? And if there's no stored information, there's no
need to modify that anyway, as the OS will just use the current time anyway.
And similar for checkout.
+ With the different mtime representations due to the different
+ platforms and locales Subversion runs on, it gets tricky in having
+ a unified mtime representation.
I don't understand you here.
Of course, the properties must be stored in some clearly defined format, and
without any locale data interfering - see my note above.
Re "Controlling the behaviour", my old branch just wrote in the properties if
they already exist.
This way the user configuration file could put an auto-prop for "svn:mtime",
and depending on the pattern match the mtime would be tracked.
I acknowledge the idea behind the other properties; but if there's a quick way
to get the first revision of a node, it's easy to get the mtime data of this
revision, too; so there may not be such a big need for the other properties.
Of course, with your definitions A,C,I are the *action* timestamps and have
nothing to do with the entry itself; so if you add/commit a big tree
structure, you'll have a big set of identical values in there.
BTW, the C is already available as revision timestamp, isn't it?
I think that they'd just increase the space needed for the repository
unnecessarily; in my commits many files are touched, and with FSFS the
properties are fully stored, not deltified.
Hope that helps!
Regards,
Phil
Received on 2009-12-21 10:02:30 CET