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
