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

Re: saving time stamps of files

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-08 22:05:27 CEST

P.Marek wrote:

>Hello!
>
>One of the main reasons I went to subversion
>(from CVS) was that it promises to keep the
>timestamps of the files.
>
>I already voted for issue #1246
>(http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
>but I'm afraid that post-1.0 is a bit late :-)
>
>Now I found the discussion on
> http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
>and I'd like to propose a solution:
>
>- the modification time of files is archived as a property, eg. svn:mtime
>- it is used on checkout
>- on update the newer of current and archived is taken
>- if the property is set to "current", the current time is always taken,
> and the property doesn't get changed on commit.
>
I really don't like this idea. First of all, we already store the
check-in time of the whole revision. I don't think there's any reason to
store the modification times of individual files; yes, I do think that
when you "svn import", all of the imported files should get the same
commit time.

The question then becomes:

    * should Subversion set the mtimes to the commit time on checkout
      and update?
    * should this be the default behaviour?

Note that using the commit time is quite sufficient for "make", even if
you have generated files in the repository; at worst, the source and the
generated file would have exactly the same timestamp after an update.

>Comments?
>When will that be finished? :-)
>
Whenever you write a patch. :-)

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 8 22:07:31 2003

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.