Branko Cibej wrote:
> Russell Yanofsky wrote:
>> ... And the issues
>> aren't that complex.
>>
> Aren't they? You haven't even spelled them out.
I haven't? What did I miss?
>> 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.
Ok, so what makes a behavior that fits the above description incorrect?
>> 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'm not waving away the issue. I'm saying that there are multiple correct ways
of choosing the directory timestamp, that different people may prefer different
ways, and that it doesn't matter very much which way you choose in the end
because directory timestamps are mostly ignored.
Consider the different meanings of directory timestamps on windows 95 and
windows NT. On windows 95, a directory is stamped once at the time of creation
and is never updated, even if files are added and removed from the directory. On
windows NT, the directories are timestamped when created, but get new stamps
whenever files are added and deleted from them.
You can't argue that one behavior or the other is incorrect. Depending on what
information you'd like to know either type of timestamp could be useful to you.
Since subversion keeps a complete filesystem history, it could stamp exported
directories with Windows 95-type timestamps, Windows NT timestamps, a unix
timestamps or a completely new type of timestamp.
>> 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.
Agreed. But AFAICT, *you* are the one proposing inconsitent behavior. The status
quo is inconsistent in two respects:
1) Files get commit timestamps while directories get stamped with the time of
export.
2) Timestamps depend on the time of export, so the an export at 5 o'clock looks
different from an export of the same revision at 6 o'clock.
>> 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.
The behavior I described would be facilitated by bubble up, but not dependent on
it. An implementation that did not use bubble up could give the exact same
results.
Personally, I think it would be great if the modification time of / reflected
changes to /foo/bar. That way you would be able to tell at a glance if something
changed recently underneath a directory, without having to look inside. But for
some reason you fancy a different behavior. That's perfectly ok too. This is a
bikeshed.
>> 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.
The current behavior is inconsistent, while the behavior Ben described is
correct and easy to implement.
> 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.
Choosing to set the timestamp on an exported directories does not in any way
constrain future design decisions. If you think it does, I'm dying to hear
how...
- 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 23:30:58 2003