[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] mtime functional specification notes

From: Ed <ed_at_kdtc.net>
Date: Mon, 04 Jan 2010 17:38:07 +0800

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

> 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.

Received on 2010-01-04 10:56:04 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.