I'm not actually opposed to the idea either. Greg makes some very valid
points. His listed reasons are why other version control systems do
retain the file time stamp data. (VSS for example)
FYI,
Bill
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
>
> 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
---------------------------------------------------------------------
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:32:27 2002