Branko Cibej wrote:
> 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.
Actually the change discussed on this thread only applies to "svn export", and
that's all I've been talking about. Switching to commit timestamps in a working
copy is messy because Subversion needs to be able to perform comparisons on
them. Timestamps are also less useful in a working copy since you can use 'svn
log' and 'svn status' to get the same type of information they provide. So
nobody is proposing to change the timestamps in working copies. (At least not
now. It is, of course, possible and I wouldn't be surprised to see it happen in
the future).
> 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.
[ I moved this quote up top since its on another fundamental issue]
If "svn export" doesn't set timestamps, the exported files and directories still
*have* timestamps, but they are set nondeterministically and don't convey much
meaning. So you wind up with something like:
foo.c 03:00:00
bar.h 03:00:01
baz.s 03:00:02
bum/ 03:00:03
bum/bitty.h 03:00:03
I don't really have a problem with this behavior, but I can understand if some
people prefer to have their "last modified" timestamps indicating actual
modification times instead of just conveying the fact that Joe Release Manager
began his export at 3 am and waited four seconds for it to finish.
Anyway, Ben recently committed a change that allows the last modified times of
individual files to be set to the commit times of the revisions in which they
were last "modified" (for some reasonable and easy-to-implement definition of
"modified"). So if the sources were last modified and checked in at 1 am, the
result is now:
foo.c 01:00:00
bar.h 01:00:00
baz.s 01:00:00
bum/ 03:00:03
bum/bitty.h 01:00:00
I *do* have a problem with this behavior because it treats directories
differently than files, and for no good reason. (You mentioned filesystem
semantics, Branko. Do you actually think that making file times represent commit
times, and directory times represent export times is a good choice of
semantics?)
Luckily though, Ben was discussing a way to do the same thing for directories as
he did for files (again, choosing some reasonable and easy-to-implement
definition of "last modified") until you jumped in with vague prophecies of
"danger" and apparently scared him off. I've been following up find out what in
the world you mean by danger and I think I know now. So, to answer your question
about reasons for and against, here's where we are now:
REASONS FOR MODIFYING DIRECTORY TIMESTAMPS ON EXPORT
-----------------------------------------------------------
1) It gives deterministic behavior. Timestamps will be the
same no matter when or where a particular revision
is exported instead of reflecting the time and
duration of the checkout.
2) Files and directories will no longer need to have their
last-modified times interpreted differently. They
will both refer to commit times instead of files
referring to commit times and directories to export
times.
REASONS AGAINST MODIFYING DIRECTORY TIMESTAMPS ON EXPORT
-----------------------------------------------------------
NONE
>>>> 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?
Right. Thats why I said "a behavior" instead of "the behavior." A behavior that
fits the description is correct for any of the definitions of "modified" we've
discussed including the Windows 95 definition, the Unix/NT definition, the
"bubble up" definition, and any variants that do or don't count property changes
as "modifications".
I have no idea why any of these behaviors would be considered incorrect, so I
was hoping you'd pick a behavior and say what was wrong with it.
> ...
>>> 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.
We are obviously talking past each other here. You're on changes to working copy
code and I'm on exported directory timestamps. Still, the only reason you'd have
to do a major rewrite is if you wanted to change your design and the existing
code prevented your from doing so. You implied that setting directory timestamps
could neccessitate a major rewrite so I wondered what bearing directory
timestamps had on any larger design issue.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 11 11:09:50 2003