You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Dickie <gr...@max-t.com> on 2002/12/06 12:13:48 UTC
file times
Hi,
We are transitioning more developers to subversion and the response seems
quite good but I've had a couple of questions about how subversion handles
file timestamps.
- On checkout all files have the current time, this is different compared to
CVS for example.
- When importing source all files take the current time rather than the
filesystem time.
Is there a reason for this?
BTW: I'm stilling hoping to get to doing up an xdiff patch, I good busier
suddenly :-(
thanks alot,
Greg
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: file times
Posted by Greg Dickie <gr...@max-t.com>.
On Friday 06 December 2002 08:46, Ben Collins-Sussman wrote:
> Greg Dickie <gr...@max-t.com> writes:
> > Hi,
> >
> > We are transitioning more developers to subversion and the response
> > seems quite good but I've had a couple of questions about how subversion
> > handles file timestamps.
> > - On checkout all files have the current time, this is different
> > compared to CVS for example.
> > - When importing source all files take the current time rather than the
> > filesystem time.
> >
> > Is there a reason for this?
>
> Subversion doesn't mess with timestamps or permissions at all, other
> than possibly tweaking an executable bit (if you have svn:executable
> set.) Files within within the svn repository are virtual: they have
> no timestamp properties. When files are imported, they become
> virtualized in a single repository revision. The original filesystem
> timestamps are lost. When you checkout, the files all have the
> timestamp when they were created in the "real world" of your working
> copy, which is the current time.
>
> 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 haven't decided whether its a problem or not but it does seem
counter-intuitive. In any case I suspect it would be pretty easy to do, all
the information exists. I guess it should be fine.
thanks,
Greg
--
Greg Dickie
just a guy
Maximum Throughput
greg@max-t.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: file times
Posted by Bill Tutt <ra...@lyra.org>.
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
Re: file times
Posted by Greg Hudson <gh...@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
Re: file times
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Dickie <gr...@max-t.com> writes:
> Hi,
>
> We are transitioning more developers to subversion and the response seems
> quite good but I've had a couple of questions about how subversion handles
> file timestamps.
> - On checkout all files have the current time, this is different compared to
> CVS for example.
> - When importing source all files take the current time rather than the
> filesystem time.
>
> Is there a reason for this?
Subversion doesn't mess with timestamps or permissions at all, other
than possibly tweaking an executable bit (if you have svn:executable
set.) Files within within the svn repository are virtual: they have
no timestamp properties. When files are imported, they become
virtualized in a single repository revision. The original filesystem
timestamps are lost. When you checkout, the files all have the
timestamp when they were created in the "real world" of your working
copy, which is the current time.
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. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org