Russell Yanofsky wrote:
>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?
>
Well for one thing, you didn't even start on the interactions between
changing directory timestamps and what happens in the WC during
different SVN operations. There's a farily large number of cases that we
have to consider. Remember, this is not just about "svn export", it's
about "svn update" and "svn commit", too.
>>>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?
>
We didn't even decide what "modified" means, right?
>>>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.
>
Sigh. You keep on talking about behaviour on various filesystems. What
we have is a _versioned_ filesystem plus a working copy; with whole
dimensions of behaviour that aren't even applicable to ordinary file
systems.
>>>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:
>
No, I am not proposing it. What I'm proposing is to leave well enough
alone until we _do_ figure out what's consistent.
>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.
>
You described a behaviour that you think would be good, but you haven't
demonstrated that it's resonably or self-consistent. So yes, you're
talking about a bikeshed, but _I'm_ talking about sitting down and
figuring out a good design. Two different things, wouldn't you say?
>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.
>
How d'you know it's correct without exploring all the edge cases and
interactions with svn operatoins?
>>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...
>
>
Did I say it constrains future design decisions? I did not. I said want
to see a good design that considers all aspects of the feature before
anyone starts hacking away, so that we don't end up rewriting the thing
500 times.
Did you notice that there's been no talk yet even about _why_ we should
modify timestamps on directories? There can be more than one reason. You
should start by making a list of the possible reasons for and against,
and comparing the merits of each. _Then_ we can start making decisions.
Maybe you think that's too much work for such a "trivial" feature. Well,
Subversion didn't get where it is now by pooh-poohing away issues like
this as trivial. Witness how much discussion was spent on _file_ mtimes
before we finally got that feature in. Directory mtimes are an order of
magnitude more complex.
--
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 Fri Jul 11 00:58:05 2003