[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: Russell Yanofsky <rey4_at_columbia.edu>
Date: 2003-07-10 11:17:36 CEST

Branko Cibej wrote:
> ...
> It's not about whether dir mtimes can/should be set, but _how_ to do
> it correctly in a version-controlled environment.

Ok. I (and apparently Michael Wood and Jack Repenning) thought you were also
making an argument again directory mtimes on grounds of OS limitations.

>> 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.

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"

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.

I think the best thing to do now is to choose whatever meaning of "modification"
gives the simplest implementation. 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.

But just about anything is better than the current behavior of stamping files
with commit times and directories with the time of export.

- Russ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 10 11:23:16 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.