At 7:51 AM -0500 7/9/03, Ben Collins-Sussman wrote:
>Branko âibej <brane@xbc.nu> writes:
>
>> I don't know if there's a danger, but someone (you? :-) has to think
>> about whether it's consistent. Can files in the directory have mtimes
>> newer than the directory itself?
>
>Nope, because of the bubble-up effect in the repository. For example,
>the last-commit-time of '/' is always equal to the date of the last
>commit.
Wait a bit. Is Ben answering the question Branko asked?
In the file system, directory mtimes are
typically unrelated to content mtimes. In Unix,
changing the file does not change the directory,
only creating, removing, renaming files does
that. (If you think your editor updates the
directory mtime when you change a file, you
should study "M-x apropos backup-by-copying";-).
But conversely, some of those directory-changing
operations have no effect on the file (e.g.,
renaming). So the directory might be newer or
older than its contents, and directory mtime
can't be taken to tell you anything about
content. In DOS, there's even less correlation.
In the Subversion repo, there's that bubble-up
thang, a necessary price to pay for O(1) tagging,
which means there is a very definite relationship
between directory and content mtimes.
But in the Subversion working copy, there may be
mixed revisions within a directory, and there may
be arbitrary mere filesystem operations after
Subversion imposes its will. In general, there's
no clear probability that the wc follows *any*
pattern!
I think here again, the best we can promise is
that immediately following an export or checkout,
the mtimes have some pattern. Anyone who needs
the wc mtimes to tell them something will have to
settle for having this only in ex nihilo WC's.
So hey, why not set dir mtimes to commit times in
these and these only circumstances?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 9 18:38:24 2003