From dev-return-820-daniel=haxx.se@subversion.apache.org Mon Jan 4 10:56:04 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o049u3Id009620 for ; Mon, 4 Jan 2010 10:56:03 +0100 Received: (qmail 3623 invoked by uid 500); 4 Jan 2010 09:55:56 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 3607 invoked by uid 99); 4 Jan 2010 09:55:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 09:55:56 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ed@kdtc.net designates 218.103.122.177 as permitted sender) Received: from [218.103.122.177] (HELO kdtc.net) (218.103.122.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 09:55:49 +0000 Received: from [192.168.8.28] (crazycat [192.168.8.28]) (authenticated bits=0) by kdtc.net (8.14.3/8.14.3) with ESMTP id o049wdHQ025338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Jan 2010 17:58:43 +0800 X-Authentication-Warning: kdtc.net: Host crazycat [192.168.8.28] claimed to be [192.168.8.28] Message-ID: <4B41B6FF.2050806@kdtc.net> Date: Mon, 04 Jan 2010 17:38:07 +0800 From: Ed User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090410 SeaMonkey/1.1.16 MIME-Version: 1.0 To: dev@subversion.apache.org Subject: Re: [RFC] mtime functional specification notes References: <20091221022943.M41235@kdtc.net> <20091221081807.M22737@kdtc.net> <4B2F340B.7040307@xbc.nu> <200912211001.55685.philipp.marek@emerion.com> In-Reply-To: <200912211001.55685.philipp.marek@emerion.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 192.168.8.27 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