[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-06-24 18:05:43 CEST

"Ph. Marek" <philipp.marek@bmlv.gv.at> writes:

> But the use-case where non-source files are versioned (1), and these
> files are in a format which prohibits saving a version in them (2),
> leads me to think whether there should be a property (3) which says
> "on updating, if the file has no local modifications (ie, clean from
> the repository), use the mtime of this file's version; if it's
> modified, use the current time." [...]
> So the user can decide on a per-wc-base if it's source-files where the
> timestamp in needed in the tool-chain, or if it should be restored with the
> file(s) for easier version tracking by the user.

Philipp, you're terrifying me. :-) Your proposal, so far, is to add
at least three humongous new features:

  1. so far, your patches have tried to create a new 'svn:' property
     for original timestamp preservation, so imports can remember the
     original unversioned mtime, rather than the commit-time. You've
     even proposed a whole new class of 'noneditable' properties
     living in the editable user space. (I think you started coding
     this before you realized we already non-editable 'entry' props
     living in .svn/entries... but still...)

  2. You want a new property for binary-files that determines whether
     to use the commit-time or 'now' time.

  3. Your solution requires property inheritance, which is another
     feature we don't have, and have discussed many times. (It's very
     *hard* to implement that, and it's been punted many times.)

At the moment, I still feel like the best solution is to mimic the CVS

  * it keeps developers and release-managers happy 90% of the time, and
    easily ignorable by people who don't care.

  * no surprises for former CVS users.

  * it only requires extremely trivial code changes; no new
    properties, no stored properties, no huge new features. Just a
    small tweak to libsvn_wc.

In other words, it's a path of very low resistance, but still
"scratches the itch" of timestamps pretty effectively.

Phillip, can you talk about why you like/dislike the CVS behavior?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 24 20:07:55 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.