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

Re: FW: Import and Commit and file modification times

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2005-08-22 13:49:13 CEST

On Saturday 20 August 2005 00:33, Michael Sinz wrote:
> Svante Seleborg wrote:
> > That is not what is at issue here. We're discussion the future design of
> > how to handle filesystem timestamp metadata.
>
> Ahh, but you have brought up that is what SVN does today, which
> is not true. The timestamp is not the only indicator/exclusive
> indicator of file changes.

Just to throw my ¤0.02 into the pool - my thoughts were approximately these
(was some time ago - may 16th, 2003
http://svn.haxx.se/dev/archive-2003-05/1360.shtml :-)

- As all meta-data it should be versioned. (Doesn't need much space, after
all)
- Should be tuneable per-file (property is needed on file or directory to be
set)
- To preserve performance as much as possible the wc-property is set to the
*real* value only on commit. So a file/directory has to be committed to have
it's property set, and to be committed it has to have text-changes (is that
still so?).
- In the first patches I had some code which tries to handle conflicts in the
text-time property; it worked by taking the newer of the two, or taking the
file's real modification time (the time of the merge). As we didn't use
branches then I think I dropped it in the newer versions.
- On update/checkout/export the text-time is simply taken and used.
- There's no saving of the creation-time; the mtime is all I ever needed, and
talking users to tell me the creation time was always cumbersome, and mostly
void, as eg .zip doesn't carry the ctime, only mtime.

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 22 13:51:59 2005

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.