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
