timestamp preservation design (issue 1256)

As a wise fictional character once said, it's not the answers that
hard, it's asking the right questions.

Let's begin by describing exactly what svn does/doesn't do right now:

  * Entering the repository (import, add, commit):

     We do nothing, no timestamp metadata is preserved. All files in
     the changeset share a single "commit time" as metadata (the
     revision's svn:date property.)

  * Exiting the repository (checkout, export, update/switch):

     Working-file timestamps are untouched, they reflect the moment
     they were created or updated. Each file's "commit time" is
     metadata in the .svn/entries file.
  
     Furthermore, the working-file's timestamp is recorded in
     .svn/entries, so that libsvn_wc can very quickly determine if the
     file has been modified.

Ghudson has pointed out that two different designs have been bantered
around for making the svn client "set timestamps". Here they are.

1. The "Simple" Approach

  * Entering the repository:

     Still do nothing.

  * Exiting the repository:

     Working-file timestamps should be set to the "commit time" of
     their last changed revision.

2. The "Complex" Approach (this seems to be what P.Marek has been
    working on)

  * Entering the repository:

     Remember every timestamp, save it in the repository somehow.

  * Exiting the repository:

     Recover the original timestamp. The "commit time" only exists as
     queryable metadata.

  * Example:

     foo.c, under version control, is locally modified at time X, so
     the OS gives it timestamp X. It is then committed to the
     repository. The repository remembers foo.c's timestamp X, even
     though the revision's commit-time is X+1. Somebody checks out a
     working copy and gets foo.c with timestamp X. Only by running
     'svn info' (or other commands) can they see that it was last
     changed in revision N, committed at time X+1.

These two behaviors seem mutually exclusive. That is, they can't
both be in effect at the same time.

*** Criticism against complex approach:

mbk points out that the complex proposal is inherently dangerous,
because of clock-skew problems between different client machines.
There's a very good maxim which says, "Only the server ever creates a
timestamp", which the simple proposal fulfills.

*** Criticism against the simple approach:

mbk points out this from the CVS manpage:

<mbk> -M[rev]
<mbk> Set the modification time on the new working file
<mbk> to be the date of the retrieved revision. Use this
<mbk> option with care; it can confuse make(1).

For example, if you backdate a working copy via 'svn up', a .c file
will have an older timestamp than it's .o, even though the .o *needs*
to be rebuilt. But 'make' won't do it. So how does the simple
behavior help build systems at all?

*** An open question to this list:

  What exactly does CVS do, and how does it justify the behavior?
  What do CVS users think of it?

For the record: I don't want to get into UI issues just yet. I
understand that whatever behaviors svn implements, we'll need a UI to
activate/deactivate it, either through props, or runtime config, a new
subcommand, or a 3rd party tool. But please, let's not discuss that
yet. First, I want to define the behavior we want, *then* I want to
discuss the UI.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 19 17:39:12 2003