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

Re: cvs commit: apr/test testfileinfo.c

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-07-10 21:53:15 CEST

Russell Yanofsky wrote:

>Branko Cibej wrote:
>
>
>>>I think it would be a mistake to treat file times differently than
>>>directory times without some specific reason for doing so.
>>>
>>>
>>>
>>It would be a vastly bigger mistake to start fiddling with directory
>>mtimes without understanding the issues.
>>
>>
>
>You're overstating. Ben could choose to stamp all directories with his birthday
>and it probably wouldn't break a thing. And the issues aren't that complex.
>
Aren't they? You haven't even spelled them out.

>I think everybody can agree that a good behavior is one that sets the last
>modified timestamp of each file and directory to the commit time of the revison
>in which that file or directory was last "modified"
>
No, the only good behaviour is one that's correct, for some definition
of correct. We don't even have an idea about that right now.

>You could debate endlessly about whether to count.property changes, or changes
>to a file underneath a directory as "modifications." This is a bikeshed issue
>though, and I don't have any opinion on it.
>
It is definitely _not_ a bikeshed. It is a very basic question of the
semantics of the SVN filesystem. We've copied most of the behaviour from
Unix filesystems, but not all by a long shot. We're talking about basic
filesystem design issues here; just because they're simple and easy to
understand for files doesn't mean you can just wave them away for
directories.

>I think the best thing to do now is to choose whatever meaning of "modification"
>gives the simplest implementation.
>
Almost -- not just the simplest, but one that's consistent in all
circumstances.

>Due to bubbling up, this should mean that a
>directory will get assigned the timestamp of the most recent revision with
>changes to files or properties underneath it.
>
I say again: bubble-up is an implementation detail. Changes that result
_only_ from bubble-up should not affect the filesystem's behaviour. When
you commit /foo/bar, you don't commit a change to / at the same time.

>But just about anything is better than the current behavior of stamping files
>with commit times and directories with the time of export.
>
>
I disagree. We should leave well enough alone until we figure out how to
do things correctly. We don't want to repeat the mistake we made with
first the filesystem schema design, which had to be changed several
times (once in a major way) to get us to the point where it's _almost_
correct.

-- 
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 Jul 10 21:56:17 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.