[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: file times

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-12-06 15:10:46 CET

On Fri, 2002-12-06 at 08:46, Ben Collins-Sussman wrote:
> I don't think this is deliberate... I just don't recall this
> discussion ever coming up before. Nobody seems to have noticed or
> cared. :-)

I think we've talked about it a bit. I've at least made off-hand
comments.

We don't mess with file metadata a lot because we've become resistant to
feature creep (especially in the wc, which already has a lot of hair to
deal with because of mixed-rev working copies) and because they present
Unix/Windows portability issues. That's kind of ironic, because it
looks like properties were initially conceived of as a way to help us
version exactly this kind of data in a less hackish way than CVS does.

Here is the case for versioning timestamps. I don't think it's a
compelling case for 1.0, but maybe some day.

One of the common uses for a version control tool is the maintenance of
local modifications to software written elsewhere. If you maintain a
lot of different locally-modified software like this, you don't want to
be importing CVS checkouts; you want to import release tarballs which
contain all the auto-generated files (configure, Makefile.in, etc.).
That way you don't have to become extra-friendly with every package's
developer build system requirements.

Unfortunately, version control systems don't tend to preserve the
timestamps on files when you import a package and then check it out.
(With CVS, if you import -d and then checkout, the timestamps are
preserved, but they will be munged on updates. And by importing with -d
you've rewritten your repository's history. So it's far from ideal.)
That tends to make the auto-generated files look out of date with
respect to the files they came from. As a result, many packages' build
systems will try to recreate the auto-generated files, which (a) causes
spurious changes to your working copies, (b) prevents builds from
read-only source directories, and (c) gets you back into the business of
having to be extra-friendly with every package's developer build system
requirements.

If you complain to the authors of, say, automake (e.g. by asking them to
avoid rebuilding auto-generated files in the "make all" rule set), they
will generally tell you that your version control tool is broken for not
preserving timestamps. (automake actually kind of splits the difference
on this issue; a package maintainer can decide to make the rebuild rules
contingent on --enable-maintainer-mode. But if you maintain many
locally-modified packages, some of them won't have turned this option
on, so that doesn't really help.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 6 15:11:34 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.