subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed ...@kdtc.net>
Subject Re: [RFC] mtime functional specification notes
Date Mon, 04 Jan 2010 09:38:07 GMT
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


Mime
View raw message