Philipp Marek wrote:
> 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.
Hi Philipp,
Sorry for the delay in response.
>
> + 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.)
I did not know that one can store nanoseconds.
>
>
> + o if x = dir, then recurisvely f_import(x)
> typing error, multiple times.
>
Easily fixable. :)
>
> 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.
Yes. After reading Philip's post and your post, it makes zero
sense to be setting the mtimes.
> + 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.
Here is where I admit I feel like a quick hack. Of course
there must be a clearly defined format.
>
> 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.
True. I figured that if users wanted a mtime, they certainly might want
to also know when it (file or directory) was first added or committed or
imported.
>
> 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.
That's definitely true. Perhaps (possibly a quick thought hack) if
during an Add, a commit or an import, the directory's contents are
also included (unless specified in ignore item) so would an
add-mtime, commit-mtime or import-mtime be set on the directory
and it applies to its contents? Further additional files or
subdirectories have their mtimes added in the usual fashion.
(Am I making any sense here?)
> BTW, the C is already available as revision timestamp, isn't it?
Point well taken.
>
> 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.
>
Well, it was my thought that the users might want statistical
information on the original add, commit, import, merge, etc..
mtimes on their files/directories.
Thanks for the comments.
Edmund
Received on 2010-01-04 10:56:04 CET