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

Re: New user, file timestamp question.

From: Peter Poeml <poeml_at_suse.de>
Date: 2003-05-06 21:10:04 CEST

On Thu, Apr 17, 2003 at 02:54:09PM -0400, Greg Hudson wrote:
> On Thu, 2003-04-17 at 00:54, Rob Kramer wrote:
> > I asked this a few days ago, but didn't get an anwer yet. I think it is
> > because perhaps it is a Dumb Question. :)
> It's not a dumb question, but it's a problem of conflicting constraints:
> * There are reasons to want to preserve timestamps across an import
> and checkout, e.g. if you're checking in generated files and you want
> your build system to know that it doesn't have to regenerate those
> files.
> * On the other hand, if a checkout or update munges timestamps, you
> run the risk of fooling a build system into thinking a file hasn't been
> modified when it has. Consider:
> svn co project-url wc
> cd wc; make
> svn update -r oldrev file
> make
> * And, of course, we want to keep our code simple, particularly inside
> libsvn_wc where things are already a bit messy. So having a lot of
> dials and knobs isn't great either.
> We've talked about adding an svn:original-date property to at least
> remember the imported date, but I can't remember how that conversation
> turned out.

Even if preserving timestamps across an import is not supported, as far
as I can see preverving them across a checkout doesn't work either. But
the latter *does* work with CVS.

On a related issue, what about file permissions? I run a repository of a
lot of files with mode 600, and I noticed that upon checkout all files
are created with the current umask (e.g. world readable). (It is not a
build system.).

Only an "executable" flag would be retained, as it looks.

Is there no way to do retain file timestamps or permissions?


Thought is limitation. Free your mind.

  • application/pgp-signature attachment: stored
Received on Tue May 6 21:11:09 2003

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.