At 10:37 AM -0500 6/19/03, Ben Collins-Sussman wrote:
>*** Criticism against complex approach:
>
>mbk points out that the complex proposal is inherently dangerous,
>because of clock-skew problems between different client machines.
Clock skew is a problem for either approach, because it redefines
what a time actually means. The complex approach provides more
points of confusion, but not really any more failure modes: the
solution must be to keep all systems in sync, either way you slice it.
On the other hand, clock skew is *not* a problem for either approach,
because anyone asking for timestamp preservation already understands
this, and has heard of NTP.
>*** Criticism against the simple approach:
>
><mbk> it can confuse make(1).
Yes it can. This is a problem for either approach. In fact, so can
non-preservation of timestamps, though not in so many ways, and most
of them are in the "safe" direction. (The worst make problems for
non-preservation arise from the fact that the new files get
timestamped in the order they're pulled, not necessarily in the order
they're processed by make; if you version output files, they can look
like they need to be rebuilt when this is not so. You will say to me
"don't do that," but you have perhaps never worked in a system that
took hours to generate certain output files, and days to build the
entire system; it changes your perspective on these things a mite.)
make-confusion is childishly easy, a swell game any number can play,
like tormenting the cat.
OTOH, make confusion is not a problem for any of the three
approaches: the make panacea is "make clean," and the rich taxonomy
of clean-like targets in most makefiles testifies that people can
learn to live with these limits.
So, if we stipulate that any use of timestamp preservation:
- requires clock syncing, and
- requires some thought about the new disciplines of "make clean"
... then I think we've quite levelled this playing field.
What's left to explore is the use cases that create the request in
the first place (the question that comes before every question).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94015
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 Thu Jun 19 18:00:45 2003