On Jul 14, 2008, at 11:49, Oliver Betz wrote:
> "Ben Collins-Sussman" wrote:
> [...]
> > I think you're right: even if Subversion doesn't make any use of
> > the file's original mod-time, it could at least be saved in a
> > property so the information isn't lost completely.
> I'm glad to see that you also support this idea.
> [...]
> > Yes, that's exactly what it expands to. The philosophy is that
> > once objects become version controlled, the only "true" timestamps
> > which matter are the ones the repository, since the repository is
> > tracking all changes. Working copies are but shadows on the wall,
> > which can optionally be made to reflect repository timestamps.
> This philosophy is perfectly well suited for "code" in most cases
> (and I share your guess that SVN is mostly used for "code").
> But in many other cases, mtime is a _very valuable_ information and
> shall be conserved. Photographs and DLLs are both examples where the
> file creation occurs far from commit and therefore commit time isn't
> a viable alternative.
My experience is quite the opposite. mtime is almost worthless
information, except across relatively short time spans. It's simply
too fragile.
Photos: I have my cameras set to GMT and rename the
photos to an ISO8601 timestamp drived from the time stored in the JPEG
metadata upon import. This way the information about when the photo
was taken can no longer get stomped by some clumbsy program or file
system operation.
Build products: Ditto. We build our java artifacts with maven, so they
have version numbers or time-stamps in their names, which correspond
to tags in the repo. During deployment the version information is
removed from the names by the guy doing it, so sometimes he doesn't
know what f****ing version he's running, but at least I can check by
comparing MD5s to the verisons archived in the maven build repository.
(Interestingly, I can't rebuild from the tag and then compare MD5s
because JAR files store the mtime of the class files created by the
compiler and this is, naturally, the time when the compiler created
them. You weren't seriously expecting the compiler to use the mtime of
the corresponding source files for the resulting class files, were
you?)
Next issue: he had this idea that when deploying, he'd only have to
replace artifacts with newer modification times than what was already
deployed.
Query: what does "newer" mean when you've got more than one branch
being worked on? Has anyone considered that? I think he spent a week
testing the release version, when he should have been testing the
development version because the most recent builds of both were built
at the same time (on a multi-cpu box).
In short: I'm suspicious of any workflow that relies critically on
mtimes. I've seen too many things break from an over reliance on such
ephemera.
On Jul 14, 2008, at 11:49, Oliver Betz wrote:
> I also see that there are pitfalls, and I hope that the subversion
> developers find a stable and useful solution.
> BTW: I also wondered why there is "active resistance" against
> preserving mtime.
My worry with 'preserving mtime' in the repository, is that it's not
clearly defined what this should mean.
We have an n to 1 mapping problem: We have one date to work with on
the local file system: mtime, but at least three meanings we might
want to give it:
(1) The time, local to the working copy, when this file was last
updated there. (the current default).
(2) The time, local to the server, when the file was last committed.
(3) The time, local to the working copy, that the file claimed to have
as its mtime the last time it was comitted.
Currently, we have (1) and (2) available. For my purposes, (2) seems
the most natural, though (1) is the default.
What people seem to be asking for is (3), but what exactly do they
mean when they ask for this?
(a) I check out a file and then touch it, changing the mtime without
changing the contents.
Is my working copy now dirty? Is this a local modification? Do I
have a change that needs to be checked in?
Will svn revert turn the mtime back?
(b) My local clock is set to October 10, 2010. I modify a file and
check it in. What happens? Does the repo preserve this? Does it
complain?
(c) My colleague's PC has a balky clock battery. He modifies the file
and and checks it in: January 1, 1970. Should the repo respect
this too? Can I change a file in the past after I've changed it
in the future?
If this sort of thing is expected to work, then mtime perserved in the
repository is really just an property that the client happens to use
to clobber the working-copy-local mtime on checkout.
How does such a property behave on merging? Since a merge makes local
edits, which are then committed surely it's allowed to change in the
working copy. But, is that the time stamp that gets committed, or
should it be one of the other two? Or something completely different?
In short: I find option 3 (preserve working-copy mtime) worryingly
ill-defined. I haven't quite understood why option 2 (impose
last-modified time as working-copy mtime on update) isn't good enough
for the use-cases asking for option 3.
// Ben (bpsm)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-17 09:57:40 CEST