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

Re: timestamp preservation design (issue 1256)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-06-19 18:53:43 CEST

To summarize Ben's mail, we have three options presented:

  * Status quo: record only commit time; never set timestamps in wc
  * Simple approach: record only commit time; set timestamp to commit
    time in wc if asked
  * Complex approach: record mod time of file when committing; set
    timestamp to commit time or to recorded mod time if asked

I think the status quo has the important feature of being trivial to
implement. We are talking about libsvn_wc here, the library we're not
supposed to complicated before a post-1.0 redesign.

I think the simple approach has limited value, because the commit times
of a big collection of imported files are unlikely to have any useful
relationship.

I think the complex approach has value, because then you can:

  * Import code, including generated files
  * Make local mods and check them in
  * Check out the result, with --timestamps orig, or whatever
  * Build the result (or a copy of the result) without trying to
    recreate generated files

without requiring the code's build system to properly respect
"maintainer mode" vs. "non-maintainer-mode". However, it does require
modifying the entries file to remember the --timestamps option, and it
most likely requires timestamp handling sprinkled all over libsvn_wc
given how libsvn_wc is currently designed. So I'm not convinced that it
should be allowed as a 1.0 feature.

(I understand the make(1) risks of the simple approach and the client
clock synchronization risks of the complex approach. Because of those
risks, the status quo should be the default behavior.)

On Thu, 2003-06-19 at 11:37, Ben Collins-Sussman wrote:
> What exactly does CVS do, and how does it justify the behavior?
> What do CVS users think of it?

On the way in, CVS records only the commit time. The "-d" option to cvs
import will use the mod time of the imported files as the commit time,
which of course causes your repository's commit times to be a lie. (To
work around this problem, I have a perl script which "squeezes" the
timestamps of a directory so that they're all close to the current time,
but have the same relationships.)

On the way out, CVS sets mod times to the commit time when a wc file is
first created. However, when a file is updated, CVS leaves the mod time
at the current time. I have no idea what mbk's -M option is; like Jack
Repenning, I can't find it in my version of CVS.

So, if you import with the -d option and then make local mods, a
checkout will bear the same timestamp relationships, allowing you to do
the same thing as I said above. However, if you then "cvs update" the
working directory, you won't get useful timestamp relationships. So
you'd have to do a checkout from scratch each time.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 19 18:54:45 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.