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

Once more: Subversion and file modification time (mtime)

From: Robin Cover <robincover_at_gmail.com>
Date: Thu, 13 Mar 2008 02:52:51 -0500

Once more: Subversion and file modification time (mtime)
[long posting]

[1] Introduction
[2] Use case: web publishing
[3] Commentary and questions
[4] Key references: Issue 1256 and congeners
[5] Issue Description for Subversion #1256
[6] Notes
[7] Postings from 2001
[8] Postings from 2002
[9] Milestone: Initial discussions on SVN (not) storing mtime
[10] Postings from 2003
[11] Postings from 2004
[12] Postings from 2005
[13] Postings from 2006
[14] Postings from 2007
[15] Postings from 2008

[1] Introduction

This communication raises once again the question of Subversion
(not) storing/recording file mtime values in an SVN repository,
and (thus not) making last-modified date/time values available
to other SVN operations, as required by predictable classes
of end users and their documented use cases.

The goal here is to provide yet one more use case, and to seek
input from the core Subversion developer team [1n] about
realistic prospects for fixing this problem -- now documented
in several hundreds of user email messages since 2002. No
FAQ or wishful thinking is going to make this problem disappear,
as far as I can see.

If this document is rejected by the CollabNet mail gateway or
is truncated (due to length), I will find another publication
venue, and provide a URI reference on this mailing list.

[2] Use case: web publishing

The application scenario is management of versioned documents
for publication on the Web, using a simple installation
of SVN and an associated Apache web server.

Let's begin by noting what happens at publication time, from
the consumer (end user) point of view:

1. The Apache server sends out resource (document) mtime
   values per HTTP definition for Header Field
   "Last-Modified", which comes from the file system [2n]

2. Search engines, both local and remote, provide the user
   with the ability to filter/sort the search results by
   "date", corresponding to server "Last-Modified"/"mtime"
   values, based on the assumption that "mtime" represents
   something close to the "document publication date" [3n]

3. Imagine [4n] that I have a mixed document corpus in which
   some of the documents change frequently (daily, or three
   times daily) while others, such as image files, are
   never revised; some files provide administrative support
   (e.g., CSS/XSLT stylesheets) and are thus like "code"; while
   others are viewed directly via web browsers and plugins.
   The vast majority of documents (97% ) are static documents
   (e.g., PDF, PostScript, XML, HTML, XHTML, JPEG, GIF), sometimes
   packaged in ZIP and tar.gz archives. In aggregate: they total
   some 15,000+ "documents" in a collection that has been
   built and maintained for over a decade, with file "mtime"
   values spread over dates 1992-2008, and possibly earlier.

4. The documents in this corpus, therefore, cannot be surrendered
   to Subversion in 2008-03: SVN add/commit would fail to store
   the crucial mtime values, and the Apache web server + associated
   search engines would helpfully offer to let the user "sort by
   (publication) date," where all 15,000+ documents would have
   the (bogus) date 2008-03-11. Indignity! Bogosity! IOW: I cannot
   actually use Subversion (as shipped) for this application because
   I cannot afford to allow the critical document "publication"
   date information (represented by 'mtime') to be destroyed in
   the Subversion import/commit operation. It's that simple.
   About a hundred other SVN-wanna-users have so said. [5n]

5. Similarly, Web servers like Apache provide Directory
   (index) pages for document collections in a hierarchical
   file system, where clicking on the "Last modified" column
   sort button will toggle an ascending/descending file sort,
   by date. Please click a few times on these "Last Modified"
   URIs to convince yourself that if the every file was
   newly assigned a "Last modified" date of 2008-03-11, you
   and all other users would be justifiable infuriated --
   because the "Last Modified" sort function would be
   fatally broken [6n]:


6. By analogy to #4: please try to imagine a nightmare in which
   someone invaded your office or home, and assigned "now"/"current"
   (mtime) property to ALL the files on your computer -- offering
   you the following as justification: "dude! mtime values are fragile
   -- you should not be depending upon them!" The analogy is just
   this: users in Web space may have just as mission-critical a
   dependence upon valid "mtime" values for published documents
   as *you* (code-heads) have for SVN version numbers and other data
   you care about, which Subversion *does* protect. Like filename,
   probably -- dare I ask? In web publishing scenarios, end users may
   depend upon 'mtime' just as much as all users, on all platforms
   and computers, depend upon their file manager "Date Modified"
   sorting and searching function. If SVN is indeed a "better file system"
   than all the standard file systems (maybe 50 or 60), then SVN
   should provide a superset, not a subset, of the core functionality
   that all 50-60 file systems provide. File "mtime" is core, but
   SVN lost it. Narrow thinking, (arguably) botched design.

   What could be fundamentally wrong-headed about a human asking this
   real-world, real-time question: "When was this (disk) file last
   edited and last-modified (thus: "closed"), resulting in a with a new
   "mtime" value? Subversion's answer: "Gee, sorry, we have no idea:
   the SVN coder used KEYWORDS, so we immediately destroyed the basis
   for any answer at commit time. We don't know. We destroyed the
   essential information. We nuked it. Forever. Sorry: the data that
   could answer your question was committed, so your question can
   never be answered. Your data was just lobotomized."

[3] Commentary and questions

In sections [7] and following, I have provided URI references
and (sometimes) excerpts for some 440 email messages in
which the "last modified" (mtime) topic has been discussed.
Thanks to all the participants -- including code writers,
core engineers, newbies, and their correspondents. I have
collected other postings from non-tigris archives, but
have omitted them for now. My summary is uneven and flawed
[7n], but it should be useful as a valid approximation:

* issue #1256 has about 21 'cc:' subscribers, and about 20
  users have sent postings to the issue ticket requesting
  support for a timely fix, or inquiring about the proposed
  schedule for a fix, which has been delayed, seriatim,
  over several Subversion releases

* in the associated Subversion Mailing Lists [8n], some 113
  [ONE HUNDRED THIRTEEN] different users [9n] have expressed
  interest in (solutions/patches for) the problem of Subversion
  failing to store/record mtime, and otherwise to make file
  mtime available (checkout, export, etc)

* from about 500 candidate email messages read or scanned,
  some 400 or more substantively address this topic; the
  vast majority represents repeated petition from the user
  community to have their use cases taken seriously, and to
  have the problem resolved

* while the responses of the core developer team (some paid
  via CollabNet) have typically been timely and courteous,
  they do not appear to show significant commitment to
  actually solving this problem: most responses have been
  given in the form of repeated requests for clarification
  and restatement of the justification, and for detailed
  technical requirements, in some cases, along with
  evident, persistent skepticism that the user requirements
  are real

In the process of reading some 500 candidate email messages
(those from the core development team were read at least
twice, or more), I found myself astonished -- beyond belief --
at the distance between expectations and assumptions on
the part of the SVN designers and the end users: the latter
express "horror" at the totally "borked" system which destroys
vital information (metadata); the system designers scratch
their heads in disbelief that users would trust anything
so fragile as 'mtime' for any meaningful data point. Hmmm...

I may rework this memo and the research into an article
which explores the great gulf fixed between code-heads
and document-heads -- as that is one of the key diagnostics.
Meantime, I think the SVN developer team should try a little
harder to come to grips with the (real-world) reality
experienced by those for whom 'mtime' is a very valuable,
indispensable file attribute.

In this memo I largely forego detailed rebuttal of the oft-repeated
defenses offered as reasons for not weighing the 'mtime' request
more heavily. Except for now. For example, I certainly *do*
understand that files are "virtualized" in an SVN repository,
so that the storage model (bitwise) is therefore quite
different than a typical file system. So what: since the user
is entitled to demand -- at any time -- a CRC-perfect file-based
representation for any content conceived as a "file", the SVN
storage model is irrelevant to what a user might justifiably expect --
and require -- as recoverable and usable file metadata. Ben
Collins-Sussman writes on 2002-12-06 that "Files within
the svn repository are virtual: they have no timestamp
properties. When files are imported, they become virtualized
in a single repository revision..." [10n] and in 2005-06: "All of
the original metadata is lost. The working copy is just a
disposable shadow of the 'real' filesystem, so you need to
switch paradigms here." [11n] Lost?! That's enlightenment? I deny
that the any user-level paradigm shift is necessary: the files
still exist conceptually, and the association of an 'mtime' value
(thrown away by Subversion) with a file is valid, because
it's REAL: it is the last-modified ISO date of the disk "file"
on an actual file system, before Subversion trashed this valuable
data in a commit operation. From the viewpoint of some users,
for some requirements, the SVN design choice to throw away ("lose")
the file mtime attribute is a design botch. It is so, by
definition, if the data owner critically needs access to file
'mtime' for any committed file. Using keywords makes this
an even more insidious evil: 'mtime' is lost (in the working
copy) instantly at commit time.

Forever lost. That can be a good outcome ONLY if the "mtime"
value is positively hostile to data integrity, QA, and
in violent opposition to user expectation. Nobody has
suggested such, and nobody can defend it: users in fact
have manifold use cases requiring access to "mtime."

In this context -- a persistent user lament -- it seems reasonable
to ask for formal consideration of the key request: for some kind
of response sufficient to enable the hundred or more issue
'supporters' to make plans for the near term. If the
problem is not going to be fixed in the main SVN development
effort, users deserve to know this, so they can make
appropriate adjustments.

Questions: if the request/complaint from 113 users is not enough,
what number is "enough"? Maybe 1113? 11,113? Or are we faced
with the consequences of a (perhaps thoughtless) design commitment
that goes so deep that even 111,113 protests will not avail.
If the 113 requesters each send CollabNet $100: would that do
the trick? How about $200? $300? $500?

We need to know, if possible, what the corporation intends to do,
other than: (a) not review submitted patches, (b) not commit
candidate code, (c) decline to allow the fix to enter the
principal SVN development plan, (d) stall, indefinitely.

[4] ====== Key references: Issue 1256 and congeners =======

Ability to preserve last modification time (mtime) of files under
version control

Issue data for #1256 from 2008-03-11:
Reporter: flying (Alexander Grimalovsky)
Status: NEW
Priority: P3 (i.e., 3 on a 5-point scale)
Issue type: Feature
Target milestone: 1.6 consider
Issue activity: http://subversion.tigris.org/issues/show_activity.cgi?id=1256
Users cc'd: ataurog,andreasmahel,aspifox,blaghislain,bonanza,enicholson,eurbah,

Related: http://subversion.tigris.org/issues/show_bug.cgi?id=1391
  - "saving files' time stamps"
  - marked as a duplicate of 1256
  - by pll (Paul Lussier) Thu Jul 3 09:44:00 -0700 2003
  - "saves the timestamps on add, import and commit, and restores these
    on export (but not update).
  - Apparently a duplicate of 1256, possibly even 1112

Related: http://subversion.tigris.org/issues/show_bug.cgi?id=1112
  - "export/checkout should create files with mtime of last commit"
  - by baruch (Baruch Even) Fri Jan 24 12:54:00 -0700 2003
  - "CVS export/checkout leaves files with a ctime of the last commit
    (no matter what branch the change was on). Directories have the
    ctime of export/checkout. Subversions on the other hand leaves all
    files and directories with a ctime of the checkout/export time.
    This causes havoc with Makefiles that depend on timestamps, on
    those occasions where result files are checked in. The expected
    result is that all files and directories will have a ctime of last
  - Status: Resolved
  - This issue has been marked as a duplicate of 1445

Related: http://subversion.tigris.org/issues/show_bug.cgi?id=1445
  - "checkout/export must set last-commit-timestamps"
  - by sussman (Ben Collins-Sussman) Tue Jul 29 09:41:00 -0700 2003
  - "We've decided that for 1.0, 'svn co' and 'svn export' will
     create files with the last-commit-time. 'svn up' will do
     nothing special (just sets 'now' timestamp when adding or
     changing files.) This means that 'make' will always work
     correctly. This is also a really trivial change. At the moment,
     'svn export' is already calling a no-op timestamp-setting function.
     We're simply waiting for a new httpd/apr to roll out, so svn's
     function won't be a no-op. Ben will finish the 'co' part of
     this as well.

[5] ====== Issue Description for Subversion #1256 =======

"Ability to preserve last modification time (mtime) of files under
version control"

 Opened: Thu Apr 24 06:41:00 -0700 2003
 "Sometimes it is useful to preserve creation/modification time of
 a files under version control. File importing/adding/committing
 should save these times together with all other file properties
 and checkout of this file should restore these times instead of
 putting current time. But since some other cases require file's
 last modification times to be a time of checkout - best solution
 will be to have an option for svn checkout and svn export to
 preserve file modification times.

Karl Fogel <kfogel_at_tigris.org> Tue Apr 29 14:54:43 -0700 2003
Additional comments
  There have been some mailing list discussions of this over the,
  uh, years ("years"!). I don't have the threads handy,
  unfortunately. This doesn't need to block 1.0, so moving to Post-1.0.
  Note that this can be approached incrementally -- 'svn import'
  first, for example.

Karl Fogel <kfogel_at_tigris.org> Tue Jun 3 08:48:57 -0700 2003
Additional comments
   Note P. Marek's nearly-complete patch for this:
   (I think he's still awaiting feedback.) If anyone's aware of a
   more recent patch, please make a note here...

Karl Fogel <kfogel_at_tigris.org> Tue Jun 3 09:04:38 -0700 2003
Additional comments
   The feature is also discussed in this thread:
   See especially Greg Hudson's response.
   Note that there seem to be two separate-but-related issues here:
   1) Preserving file timestamps on import and add, so when
       the file is checked out again, the working file gets the
       same timestamp as when it was imported/added.
   2) Setting working file timestamps according to last commit
   I'm not sure that one necessarily implies the other, although
   they seem intuitively to go together...

Karl Fogel <kfogel_at_tigris.org> Tue Jun 3 16:00:02 -0700 2003
Additional comments
   Pulling into Beta. We'll assign a CollabNet developer to it,
   don't worry (getting it done before 1.0 turns out to be desirable
   to CollabNet, though it looks like some others will also be pleased).
   For now, assigning it to self, so people trawling for unclaimed
   issues won't be lured by this one. Note that any developer is
   free to do the same to any Post-1.0 issue. If you're willing to own
   it, you can schedule it any way you want :-). Changing to a feature,
   instead of an enhancement.

Paul Lussier <pll_at_tigris.org> Mon Jul 14 10:05:19 -0700 2003
Additional comments
   Issue 1391 has been marked as a duplicate of this issue.

Ben Collins-Sussman <sussman_at_tigris.org> Tue Jul 29 09:43:36 -0700 2003
Additional comments
   This is a much more complex "timestamp preservation system".
   Pushing back to post-1.0, and doing issue 1445 for 1.0 instead.

Etienne URBAH <eurbah_at_tigris.org> Fri Sep 10 11:04:54 -0700 2004
Additional comments
   I have to perform a lot of 'Vendor Branch Management'. That would be
   much easier with a 'timestamp preservation system' working not
   only for 'import', 'add' and 'commit', but also for 'copy' and
   (perhaps more difficult) 'merge'. So I am awaiting very much the
   implementation of this feature.

P.Marek <pmarek_at_tigris.org> Thu Nov 4 01:51:39 -0700 2004
Additional comments
   "Newer patch here:
   But not ready for inclusion, I believe.

P.Marek <pmarek_at_tigris.org> Tue Nov 9 09:21:38 -0700 2004
Additional comments
   New patch with log message here:

Max Bowsher <maxb_at_tigris.org> Fri Feb 18 13:04:12 -0700 2005
Additional comments
   Set it as a PATCH, because that's what it is, and set it as
   1.2-consider, because it deserves to be at least conciously
   evaluated before 1.2. However, I have a feeling that the design
   for this feature has never been discussed to satisfaction on
   the dev mailing list. Also, the patch is against 1.1.1, so it will
   need to be ported to trunk. Basically, what I'm saying is, that
   despite there being a patch here, there's still lots that needs
   to be done.

Max Bowsher <maxb_at_tigris.org> Sat Mar 19 06:23:13 -0700 2005
Additional comments
   1.2 draws near, 1.3-consider
   Ph. Marek has this in a branch in the repository now.

P.Marek <pmarek_at_tigris.org> Wed Mar 23 05:58:50 -0700 2005
Additional comments
   Please use the current versions from
   and not the patches. There's a readme at:
   and another branch which attempts unix-owner, -group, and -mode
   versioning too.

Karl Fogel <kfogel_at_tigris.org> Mon Aug 22 13:58:09 -0700 2005
Additional comments
   "Assign away from self."

Peter N. Lundblad <lundblad_at_tigris.org> Thu Jan 12 06:59:16 -0700 2006
Additional comments
   "Pushing to 1.5-consider, since 1.3 is released and to not bloat
   1.4 too much."

Graeme Thompson <graemethompson_at_tigris.org> Wed Mar 8 03:00:09 -0700 2006
Additional comments
   Design Discussion:
   Moving to 1.5! Delayed yet again!

Erik Huelsmann <dionisos_at_tigris.org> Wed Feb 28 08:21:46 -0700 2007
Additional comments
   Adjust summary to include more keywords which I might query for.

Daniel Rall <dlr_at_tigris.org> Fri Mar 2 15:58:09 -0700 2007
Additional comments
   "Erik, didn't you do some more recent design related to this issue?"

Erik Huelsmann <dionisos_at_tigris.org> Fri Mar 2 16:09:50 -0700 2007
Additional comments
   "Yes, I did. The proposal is here:

John D. Gwinner <jgwinner_at_tigris.org> Fri Mar 2 16:44:17 -0700 2007
Additional comments
   "I find this extremely useful - I would like to see the choice to
   preserve it, and retrieve a file with current or modification time.
   Thanks, John

Marko Kaening <kaening_at_tigris.org> Mon Mar 5 09:14:52 -0700 2007
Additional comments
   I also want to express my interest in such an option for considering
   the file modification timestamp during checkin and checkout. Marko

Eric Nicholson <enicholson_at_tigris.org> Mon Jun 4 13:41:50 -0700 2007
Additional comments
   "Add me to the list of people who think this fix would be invaluable.
   The current behavior works great for almost all of our source code,
   no problems there. But, I want to put other types of build inputs
   in subversion such as third party dlls. For that you absolutely
   need to have the correct modification date or you can really screw
   up someones PC. This would really be a "big deal" to me and, I
   imagine, anyone else who works extensively with binary files.

Dave Pawson <dpawson_at_tigris.org> Thu Aug 30 00:19:55 -0700 2007
Additional comments
   "[[ Karl states: 1) Preserving file timestamps on import and add,
       so when the file is checked out again, the working file gets
       the same timestamp as when it was imported/added. 2) Setting
       working file timestamps according to last commit time.]]
   I support this as a part of the feature request. My use case is a
   reliable backup service for my Linux box and my wifes Windows box
   (using TortoiseSVN). The issue has arisen when my server went
   down. Reloading the subversion server lost all dates on the data?
   I would be happy if it were an option which must be explicitly
   set (or configured if its wanted all the time). I doubt I'm the
   only one using subversion in this manner - it's a good tool."

Karl Fogel <kfogel_at_tigris.org> Fri Aug 31 10:07:16 -0700 2007
Additional comments
   Point (1) is worded ambiguously, so I'll clarify here: If a file
   has timestamp value X, is imported at time Y, and is checked out
   again at time Z, then the preserved timestamp should be X -- in
   other words, when checked out, the file will have timestamp X.
   (The way (1) was worded, it could have meant either X or Y, just
   not Z. Z is, of course, the current behavior.)

Pardal Freudenthal <sharebird_at_tigris.org> Mon Oct 1 11:14:30 -0700 2007
Additional comments
   Any news on this issue? I would very appreciate if this feature
   would be implemented (and I guess many other users).

John D. Gwinner <jgwinner_at_tigris.org> Mon Oct 1 14:46:39 -0700 2007
Additional comments
   "I'm interested in an update as well (/em makes the wheel squeek).
   Karl Fogel identified the behaviour we are looking for.
   Current behaviour is a deal breaker for us. John.

Marian Ciobanu <ciobi_at_tigris.org> Mon Dec 3 14:50:05 -0700 2007
Additional comments
   "This may perhaps sound extreme, but losing the modification time
   is the reason I'm not using any source control (and instead just
   keep making copies of the directories I'm interested in).

   I hope that if enough people ask for this, it will eventually get
   implemented. I know that an implementation is not as
   straightforward as it may first seem, but I still have a hard time
   understanding why Perforce, StarTeam and probably other commercial
   applications have this feature (and had it for a long time), while
   in the open-source products so few people want it that it kept
   getting postponed from one release to the next. I guess I'm
   just trying to use Subversion in another way than it was meant
   to be used, but a feature of good tools is that they can be
   used in ways that they weren't meant to.

Adam Borowski <kilobyte_at_tigris.org> Sat Dec 8 17:35:43 -0700 2007
Additional comments
   For now, there's an asvn-ish wrapper which can (crudely) do this:

Jens Langemyr <jenlan_at_tigris.org> Tue Jan 1 08:14:44 -0700 2008
Additional comments
   I find it really hard to understand how people use the system without
   preserving the original modification date, so I'm really looking
   forward to when this feature is implemented. Is there anything
   I can help with let me know.

Michael Hipp <rottweiler_at_tigris.org> Tue Jan 22 10:16:50 -0700 2008
Additional comments
   There are many applications both within and without of the
   "traditional" uses of vcs where the last-modified time is
   important information to be retained. When I first saw the current
   behavior, I was flabbergasted that this information loss was
   considered "normal". (I don't mean that as a rant, but it just
   seemed, well, obvious.) Please add my vote for getting this
   much-requested feature implemented. Thanks to all.

Philip S. Ehrens <pokute_at_tigris.org> Thu Feb 7 10:04:07 -0700 2008
Additional comments
   Please add me and my 300 users to those who require file timestamp
   preservation! Phil Ehrens, The LIGO Lab at Caltech

Pardal Freudenthal <sharebird_at_tigris.org> Sat Mar 1 20:44:54 -0700 2008
Additional comments
   I'm wondering if someone is working on this issue. I absolutely
   need timestamp preservation for my files. Please, devs, give us
   some feedback if we can expect this fixed for 1.5? It would
   make Subversion perfect!

Blair Zajac <blair_at_tigris.org> Sat Mar 1 20:47:44 -0700 2008
Additional comments
   I'm not aware of anyone working on this issue.
   It will not be in 1.5, which has already branched.

Pardal Freudenthal <sharebird_at_tigris.org> Mon Mar 3 08:14:12 -0700 2008
Additional comments
   Oh.. That's bad. I'm afraid as long we treat this as a feature
   request, we will not see any changes on it. Actually it's not a
   feature request, but a bug fix request. One simple example: if I
   make changes on files at my Work Copy and decide the changes are
   bad, I will, before commit, choose for REVERT, to have my unmodified
   files again. I expect to have no data lost with this operation.
   With the actual behavior, at the end I have the impression I
   modified the file and then modified again to make it look like
   before... Anyway, the file WAS modified.

   Maybe it's not a big deal for code in general. But for people
   which uses subversion to develop on WEB, mixing codes and graphics,
   this is really bad! Last modified time is normally the first to be
   checked on comparing files. Just a few systems (like subversion)
   are able to have a deeper look on them to decide if this file was
   really changed or not... Proposing changing issue type from FEATURE
   to DEFECT.

Aryeh Leib Taurog <altaurog_at_tigris.org> Mon Mar 3 11:23:10 -0700 2008
Additional comments
   Actually one CAN issue a revert without changing last timestamp.
   Here's a direct quote from my svn client config: [...]
   This issue here, as I understand it, is really only a question of
   how the timestamp is handled at commit time. SVN keeps the commit
   time, but not the file's timestamp at commit time. For changes made
   and committed during normal work cycle, I would guess it's usually
   not a significant difference either. I tend to make small changes,
   test and commit. So the time stamp may be an hour or two off
   down the line. The real problem, in my mind, is what happens when
   new files are added. As much as I value this feature, I tend to see
   it as such: a feature.

Karl Fogel <kfogel_at_tigris.org> Mon Mar 3 11:30:00 -0700 2008
Additional comments
   Please, let's not descend into nominalism. Calling something a
   different name isn't going to change what it is. Whatever reasons
   have resulted in this issue not getting resolved, they are not
   going to be affected by changing a string from "FEATURE" to "DEFECT".

[6] ======== Notes ========

[1n] I attempted to survey all the relevant postings from the
    Subversion Mailing Lists -- though I know I overlooked
    many. I was impressed with the responsiveness of the
    core and extended SVN developer team, including the
    response time and courtesy accorded end users who
    serially complain[ed] about the unexpected (non-)
    handling of file mtime. Some of the conversations
    required answering evident novice users of UNIX, and
    relative newbies to VCS. I am proud of the Subversion
    team's professional handling of questions, as exemplary
    for open source community development ethos.

[2n] "file modification" vs "mtime" vs. "timestamp"

    The language used in the mailing list postings is variable:
    many users say "timestamp" when they evidently mean 'mtime'
    (as opposed to POSIX 'ctime', 'atime', and other notions
    of version/time-based file metadata. For the purposes of
    this memo, all occurrences of "timestamp" and "mtime" may
    be taken as approximations of "file modification date/time"
    where we mean "content modification", and not (usually)
    "other-file-attribute" or "file-metadata" property, as
    generally representing end-user semantics in:

    * MacOS Finder "Date Modified"
    * UNIX ls -t "sort by modification time" (e.g., ls -lt1r)
    * Windows Explorer "Date Modified"

    viz., file content last modified (mtime, modification time)

[3n] on HTTP "Last-Modified" header, see the current RFC (I forget
    the number) and work-in-progress:

    HTTP/1.1, part 4: Conditional Requests [February 24, 2008]
    Section 7.6. Last-Modified
    "For files, it may be just the file system last-modified time."

    I am well-aware of the theoretical and practical hazards of
    assuming that a web-document's (HTTP) "Last-Modified" value
    can be taken as a "document publication date". Well aware.
    In fact, a "document" produced and issued as a web document
    may have a dozen or more relevant "date" values, important
    to the "publication". See ISBD, DublinCore, METS, AACR2,
    or whatever you want: I know about this. The brutal
    pragmatic fact of relevance is that for many millions of
    web users (authors, editors, publishers), the only
    machine-accessible "publication" date is file 'mtime'.
    And so, having suffered this constraint in the web world
    for many years, as a pragmatic reality, users come to
    depend upon this: both publishers and readers. For that
    reason, as discussed elsewhere, search engine UIs
    make a facile equation between what they get from HTTP
    "Last-Modified" (system timestamp, 'mtime') and
    "publication" date, even though it's a crude approximation.

[4n] The scenario described is basically factual, but conflates
    the properties of 3-4 web sites over which I have some
    control. I have been a Subversion user for about 18 months,
    as memory serves: I understand and value the benefits it
    affords in the appropriate application contexts.

[5n] From the 500-or-so Subversion Mailing List email postings I
     surveyed, three or four posters recited (as a possible
     argument for SVN's disrespect of "mtime") the claim that:
     "mtime values are fragile... some applications don't store
     them, few applications use them, and it's altogether too
     easy to break them..." On one level, I grant this: on two
     occasions, since 1989, I have suffered damage to personal
     intellectual property, at the hands of (unobserved) systems
     administration personnel who were apparently oblivious to
     the value *I* places on file mtime -- wiping out valuable
     data. On another level, I deny the relevance of the claim:
     in almost 30 years of computing, I have always chosen tools
     (or tool use) that respects "mtime," and never nukes it.
     As one poster declared: it's as natural as breathing. I
     cannot imagine using a tool that wipes out "mtime." If
     I care to actually discover and use an "mtime" value
     [a predictable daily action], why would I ever destroy it,
     or allow a reprobate, brain-dead application to destroy it?
     I could argue (but I won't) that in *my* application space,
     a filename is far less valuable than a file "timestamp."
     I leave it to the bewildered to figure out how this could
     possibly be true, and relevant, in some universe parallel
     to the one in which they live.

[6n] Use of Apache directory/index page

     Many Web applications use CMS systems that do not expose
     a hierarchical file system to end users. Typically, at the
     expense of "really bad" support for Web standards. Some might
     (thus) argue that using a raw/plain Apache index page,
     or any fancy equivalent that *directly* depends upon
     file/directory mtime, is an ugly, unbaked, uncooked,
     "bad" implementation for a Web site. Perhaps. Maybe. The
     trade-off might be: handing over valuable assets to a
     CMS or VCS system that destroys valuable information.
     Reality check:

     Google (this): Name "Last modified" Size Description

[7n] Caveats/disclaimers:

  * the compilation in [7]ff will contain many infelicities and
    errors of inadvertence (omissions, clumsy excerpting, poor
    thread-following, bad date-sorting of posts, errors of
    interpret ion, false inclusions)
  * in all cases, readers should consult original texts to
    inspect the author's words in context
  * this post comes from a casual user of Subversion, and thus
    may be flawed by misunderstandings and misinformation

[8n] Mailing Lists Surveyed
Subversion design documents
 (AWOL) http://subversion.tigris.org/project_docs.html

[9n] calculation of users supporting "mtime recording"

    Anyone could duplicate or build upon my research endeavor
    and (then) question or challenge the counts I made.
    If it makes you feel better: consider the margin of
    error to be 5% or 10% -- I was as careful as I could
    be, and know (from the asymptote) that any new research would
    result in higher numbers for (new) SVN users who are dismayed,
    perplexed, and angry about destruction of "mtime" values

[10n] http://svn.haxx.se/dev/archive-2002-12/0350.shtml

[11n] http://svn.haxx.se/users/archive-2005-06/0332.shtml
      ** Not picking on Ben: he seems to be a lead engineer,
      and the one who said about mtime (that) it was not
      even discussed. In light of 100+ user complaints,
      maybe it could have been, in some ideal world...

[7] ======== Postings from 2001 ========

   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2001-06-27 22:43:19 CEST
   [tangential: note the claim "timestamps exist merely as..."]
   "You know, I've noticed this oddness for a *long* time
   and have always wondered. It seems like the timestamps
   are always bizarre. Of course, the bug is (currently)
   harmless; the timestamps exist merely as a shortcut to
   determine if a file has been locally modified. But as
   it stands, having a bogus timestamp only removes this
   shortcut." [[Comment: I think what this means is than
   Ben would never trust an 'mtime' value in a distributed
   computing environment as anything other than an
   approximation, and that in the general case, he does not
   work in application spaces where "mtime" is valuable for
   much of anything other than "approximation", and that
   there are few other application spaces important for his
   work. If so: code-heads vs, document-heads.]]

[8] ======== Postings from 2002 ========

timestamps upon checkout
   Noel Yap <yap_noel_at_yahoo.com> !!++
   Date: 2002-10-15 17:09:56 CEST
   [the user wants a user option]
   "I understand both sides of this debate. I think there are
   situations when I would want Subversion to update the
   timestamp and other times when I don't. Can this be made an
   option? How difficult would it be? Thanks, Noel

svn status: does not notice changed file if timestamp of "new" file is older
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2002-11-12 20:51:07 CET
   [tangential only: but a significant datum in this assertion]
   "Well, heck, that's the bogosity right there. Is that
   normal on win32? When you copy a file, the timestamp
   doesn't change?? I've never heard of such a thing."
   Branko <brane_at_xbc.nu>
   Date: 2002-11-13 01:52:38 CET
   [tangential: It's a common misconception that "ctime" means
   "creation time". It doesn't. the ctime is the time of
   the last _change_ to the _inode_, and as such doesn't
   bear any relation to Windows creation time. So yes, it's
   totally wrong to rely on ctime, we should be looking only
   at mtime. It's quite possible that APR gets this wrong, too.]
   Philip Martin <philip_at_codematters.co.uk>
   Date: 2002-11-12 20:54:59 CET
   [tangent: Perhaps you have misunderstood how Subversion works:
   a timestamp change alone doesn't count as a local modification.
   We don't view this behaviour as a bug, it's been designed
   to work this way.]
   Philip Martin <philip_at_codematters.co.uk>
   Date: 2002-11-13 20:59:46 CET
   "It's possible that APR should be changed to put the more
   recent of create/last write into ctime. However that's really
   a separate issue and need not concern us, I don't think
   Subversion should be using ctime at all, it's only interested
   in the file contents. I'm going to check-in a patch to make
   svn_io_file_affected_time always use mtime, that is unless
   someone objects :)
   Karl Fogel <kfogel_at_newton.ch.collab.net>
   Date: 2002-11-13 21:05:53 CET
   No objection here. I originally had it watching ctime when
   we still thought we'd be versioning all of a file's mode bits.
   Later we decided not to do that, so the ctime check is just
   weird :-).
   John Barstow <John_Barstow_at_gfsg.co.nz>
   Date: 2002-11-13 22:02:40 CET
   [Ben Collins-Sussman: 'I don't understand. Are you saying it's
   possible for the mtime to be unchanged, but the contents have
   changed? How is that possible?']
   1) System clock reset (possibly by synchronizing with a time server)
   2) As I recall, touch can alter the timestamp to a particular value.
   3) Windows xcopy has a option to do a 'perfect' copy, with
      timestamps and permissions intact - over existing files.
   4) Buggy/experimental filesystem driver.
   5) Some backup/restore programs will restore the original timestamp.
   6) Explicitly screwing around with the filesystem APIs for proprietary

[9] ==== Milestone: Initial discussions on SVN (not) storing timestamps ====

file times
   Greg Dickie <greg_at_max-t.com> !!++
   Date: 2002-12-06 13:13:48 CET
   "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

   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2002-12-06 14:46:21 CET
   "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 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. :-)
   Greg Dickie <greg_at_max-t.com>
   Date: 2002-12-06 15:08:19 CET
   "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 Hudson <ghudson_at_MIT.EDU> !!++
    Date: 2002-12-06 15:10:46 CET
    [[ '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.)

    Bill Tutt <rassilon_at_lyra.org> !!++
    Date: 2002-12-06 15:31:42 CET
    "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

[10] ======== Postings from 2003 ========

   Baruch Even <baruch_at_ev-en.org> !!++
   Date: 2003-01-24 20:16:40 CET
   [tangential: SVN was apparently fixed to match (viz., be
   competitive with) CVS functionality]
   "My problem is that when I do 'svn export url' the last changed
   time of the files is that of the export itself, while I expect
   it to be the time of the last commit. I expect the same for
   a checkout."

Retaining file timestamps at import/commit
   Rob Kramer <rob_at_infologic.com.sg> !!++
   Date: 2003-04-15 09:52:40 CEST
   "Hi, I'm trying to 'retrospectively' import a project.
   I've got a bunch of older versions stored in several directories:
   drwxrwxr-x 2 root ildev 3072 Jun 6 2002 ismncc.5.20
   drwxrwxr-x 2 root ildev 2560 Jun 24 2002 ismncc.5.21
   drwxrwxr-x 2 root ildev 2048 Jul 15 2002 ismncc.5.23
   drwxrwxr-x 2 root ildev 3072 Nov 17 05:17 ismncc.5.24
   drwxrwxr-x 2 root ildev 3072 Nov 17 05:17 ismncc.5.25
   So I want to:
   - import ismncc version 5.20,
   - check it out somewhere,
   - copy 5.21 on top, fix added files etc, and commit 5.21.
   - etc, until current version.
   Now, can I do this while keeping the original timestamps of all
   the files? I tried (in CVS also), but after an import all
   timestamps are set to the current time. CVS has an import -d
   flag (which doesn't work for client/server CVS). Same for
   commit: can I commit 5.21 and keep the timestamps from the
   ismncc.5.21 directory?

New user, file timestamp question
   Mark Swann <mswann_at_echo-inc.com> !!++
   Date: 2003-04-17 00:39:03 CEST
   "(Win2000) I downloaded Subversion 0.20.1, installed it,
   created a new repository, imported some files and checked
   out the files into a new workspace. Why are the time stamps
   in the workspace files different than the time stamps in
   the original files? Can this be corrected? Is it corrected
   in a later revision? The date of last modification is as
   important as the contents of the file. Mark Swann ECHO, Inc.
   Rob Kramer <rob_at_infologic.com.sg> !!++
   Date: 2003-04-17 06:54:34 CEST
   "Hello Mark, 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. :) I was thinking about my problem a bit more
   (importing some really old versions of a project to create
   a SVN history for it), but don't think it would be possible
   at all. You'd have to import files that are older than the
   current repository, so you'd have to change the repository
   in the past. I can imagine that would be a nasty thing to
   do. Losing file timestamps is an obstacle in getting my
   company to switch to a source version control system -
   everybody uses file dates to track the versions here (and
   it gets messy sometimes). I use CVS for my projects and
   never use timestamps to track history. Will switch to SVN
   one of these days, when I'm convinced cvs2svn works fine.
   Maybe it already does :) Cheers, Rob
   Sander Striker <striker_at_apache.org> !!++
   Date: 2003-04-17 07:10:24 CEST
   [Losing file timestamps is an obstacle in getting my company
   to switch to a source version control system - everybody
   uses file dates to track the versions here (and it gets
   messy sometimes).] Ouch! That is just plain nasty. It will
   all fall down when someone sends another person an older
   file which gets a new timestamp... Sander
   Greg Hudson <ghudson_at_MIT.EDU>
   Date: 2003-04-17 20:54:09 CEST
   "It's not a dumb question, but it's a problem of conflicting
   * 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.
   * 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.

Re: New user, file timestamp question.
   Peter Poeml <poeml_at_suse.de> !!++
   Date: 2003-05-06 21:10:04 CEST
   "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? Peter
   C. Michael Pilato <cmpilato_at_collab.net>
   Date: 2003-05-06 21:15:15 CEST
   [Is there no way to do retain file timestamps or permissions?]
   "The short answer: no. The long answer: don't get me started
   on what a Version Control system is and isn't."

saving time stamps of files
   P.Marek <pmarek_at_cpan.org> !!++
   Date: 2003-05-08 11:33:12 CEST
   "Hello! One of the main reasons I went to subversion (from
   CVS) was that it promises to keep the timestamps of the
   files. I already voted for issue #1246
   but I'm afraid that post-1.0 is a bit late :-) Now I found
   the discussion on
   and I'd like to propose a solution: - the modification time
   of files is archived as a property, eg. svn:mtime - it is
   used on checkout - on update the newer of current and
   archived is taken - if the property is set to "current",
   the current time is always taken, and the property doesn't
   get changed on commit. Comments? When will that be finished?
   :-) I'll be trying 0.22 now, as I had some problems with
   the older revisions (issues 1284 and 1288).
   From: Greg Hudson <ghudson_at_MIT.EDU>
   Date: 2003-05-08 17:45:08 CEST
   "This seems like reasonable default behavior, although I'm
   not sure about the real necessity of "current". I guess
   I'd be +0 on a patch which did this. (I'm not +1 because
   it does introduce new complexity into libsvn_wc, something
   we like to avoid.)"
   From: P.Marek <pmarek_at_cpan.org>
   Date: 2003-05-09 08:33:20 CEST
   "I meant not to use the current time but the current file
   mtime and the mtime of the newer revision of the file.
   I grant that it depends on the usage. But saving the mtime,
   having options to checkout and update AND per-file-properties
   specifying default behaviour should get all cases. Maybe
   setting a directory-property which is used by all files and
   subdirectories below could do the trick - but I have a feeling
   that this isn't the simplest (as in KISS) solution.
   From: Branko <brane_at_xbc.nu>
   Date: 2003-05-08 22:05:27 CEST
   "I really don't like this idea. First of all, we already
   store the check-in time of the whole revision. I don't
   think there's any reason to store the modification times of
   individual files; yes, I do think that when you "svn import",
   all of the imported files should get the same commit time.
   The question then becomes:
   * should Subversion set the mtimes to the commit time on
   checkout and update?
   * should this be the default behaviour? Note that using
   the commit time is quite sufficient for "make", even if
   you have generated files in the repository; at worst,
   the source and the generated file would have exactly the
   same timestamp after an update.
   Jack Repenning <jrepenning_at_collab.net>
   Date: 2003-05-09 17:55:31 CEST
   "Historically, "exactly the same time on source and generated"
   has had indeterminate effect in various makes. I don't
   know if that's still an issue -- it started to pass away
   when one second (granularity of filesystem timestamps)
   started to be "a really long time." In any case, I don't
   see how using the commit timsestamp addresses the interleaved
   operation problem.
   P.Marek <pmarek_at_cpan.org>
   Date: 2003-05-16 13:05:33 CEST
   "Well, here is part 1. This just saves the mtime of the files
   in a new property, so this patch is trivial. As for part 2
   - restoring the time stamps: With this in mind I'd propose
   that (1) - export uses the archived time stamps, ie. the
   mtime of the files. (2) - update uses the current time
   (3) - both get switches to override this default behaviour.
   In my first try for part 2 there won't be another property
   for specifying the default (use saved time or current),
   although in my patch I've already reserved a property name.
   Could I please get some other opinions to a new question
   which arrived in my head: should binary files be treated the
   same as text-files? The reason I ask this is because binary
   files tend (at least in my usual usage patterns) to be the
   end-product of some process, and they are seldom used as
   dependencies for other programs. This is to say, the .o-files
   are mostly not archived in a versioning system, the output
   files are endpoints and do not present dependencies of other
   files, etc. Of course I think about the use of e.g., pictures,
   which are linked into a binary ... but is this a very common
   case? I do not argue that this cases should be forbidden.
   I think about whether the default behaviour for mtime
   restoring should be on for binary and off for text files,
   with the command line switches able to override that, and
   possibly (but as mentioned not in the first patch) to still
   have a per-file-property as last resort."
   Karl kfogel <kfogel_at_collab.net>
   Date: 2003-05-16 20:20:00 CEST
   [P.Marek 'pmarek_at_cpan.org' writes: 'default behaviour for
   mtime restoring should be on for binary and off for
   text files, with the command line switches able to
   override that, and possibly (but as mentioned not in
   the first patch) to still have a per-file-property as
   last resort...] "I think this behavior should treat all
   files the same. That's easiest to explain and remember.
   Regarding the patch: Can you write a log message (see
   HACKING, and run 'svn log' on the Subversion repository
   to see examples)? Also, it's easier for us to apply patches
   when they are relative to the top of the source tree.
   Comments follow: [...] Looks basically good, though please
   clean up the alignment so it's easy to read! :-) (For
   example, "apr_time_t tstamp" above.) Is there any way
   to write a regression test for this? That would be very
   helpful. -Karl
   P.Marek <pmarek_at_cpan.org>
   Date: 2003-05-19 10:11:47 CEST
   "I'll do what I can. I even wrote some lines in the
   doc/book/ch06.xml :-! But for now I've got a problem. I'm
   not very familiar with subversion as I started coding Friday.
   Philip Martin <philip_at_codematters.co.uk>
   Date: 2003-05-16 21:13:39 CEST
   "This saves the file's mtime when an 'svn add' command is run,
   but I can't see any point in doing this. A complete system
   for storing mtime is going to need to retrieve and store
   it when 'svn commit' is run, and once it is getting done
   at 'svn commit' it is pointless to do it at 'svn add'.
   Philip Martin
   P.Marek <pmarek_at_cpan.org>
   Date: 2003-05-21 17:03:35 CEST
   "Hello everybody, I finally made it so include the mtime
   in the item->wcprop_changes array (svn_client/commit_util.c,
   do_item_commit()). But that doesn't work as a few lines
   after my change the file .svn/wcprops/ is synced with
   the repository; as I include the property currently only
   in the item->wcprop_changes, it isn't written into the
   repository. (there's another problem: I had to create
   the property-files with len 0 to avoid an error while
   transmitting in svn_io_copy_file()). So, where's the best
   place and what's the best strategy to set this property?
   I assume writing an (empty) property on update/checkout
   is the easiest solution; is there a better one? I also
   think that simply overwriting that value isn't good; if
   the user wants to set another file-time he should be
   able to. But that could possibly be done by using "touch"
   ... Hm. Any ideas? Help please?? Thanks a lot!
   Karl <kfogel_at_collab.net>
   Date: 2003-05-21 19:55:37 CEST
   "This is for a specific issue, right? Umm... is it
   issue #1162? Or #1256? (Hard to prioritize without
   knowing the goal.) Thanks, -K
   P.Marek <pmarek_at_cpan.org>
   Date: 2003-05-22 06:55:19 CEST
   "It's issue #1256. My problem is, that svn syncs the
   *file* with the properties to the repository, not the
   internal data structures; so I'd have to modify the
   property file, which is inelegant, slow (1) and error-prone.
   1) setting the property via modifying the .svn/props/
   file, if it is done via the "normal" functions, results
   in a complete reading of the file (although the values
   are in memory at this time), appending to the memory data
   structures, writing a temporary file, chmod()ing the
   property file, renaming the temporary file to the correct
   name, chmod()ing the file. I'd like to avoid that overhead,
   but it seems to be not easy. I understand and acknowlege
   that it's much simpler (and therefore *better*) to have a
   single synchronize-call, which is used everywhere, for
   data files and properties. So I ask if there's a simple
   solution, which avoids doing the equivalent of "svn st",
   setting svn:text-time on every file, and then calling
   "svn ci". Maybe I can send a property change at the end
   of the file-stream (but before the file's data)?? I think
   of svn_client__do_commit() in the first loop. Comments??
   Karl <kfogel_at_collab.net>
   Date: 2003-05-22 21:28:50 CEST
   "Thanks. Issue #1256 is marked as a Post-1.0 enhancement
   -- that's probably why you're not getting much feedback.
   I hope someone can take an interest and give you some
   code review, but can't guarantee that will happen. For
   an issue of such relatively low priority, it's just hard
   to justify the time right now. Sorry, I know that's
   probably disappointing, but then again, you picked the
   issue :-). -Karl

strategic question regarding saving time stamps (what else :-)
   P.Marek <pmarek_at_cpan.org>
   Date: 2003-05-22 12:14:17 CEST
   "I'm finally getting some hang of the organization of the code.
   Now I've come to the conclusion (which can be bad - please
   tell me) that it would possibly be a sane way to have
   svn_wc__load_prop_file() do the insertion of the
   text-time-property, as this is called from several places
   (around 10, IIRC). In order to do that I'd have to give the
   filename of the text-file to the function - which looks a bit
   ugly (propfile_path, hash, pool, and text-file?). I could
   start a new function which would just insert this hash value,
   but that doesn't change the problem that I don't know the
   original file name. Help, please?? Regards, Phil

Re: saving time stamps of files - nearly finished, help still needed
   Norbert Gruener <nog_at_MPA-Garching.MPG.DE> !!++
   Date: 2003-06-12 11:49:25 CEST
   "Hi Philipp, on the "subversion" mailing archive I have read your
   thread about "saving time stamps of files". I am very interested
   in that {feature|option}... [Will that possibly be in 0.23 or
   0.24? I'd like to have an "acknowledged" version, which
   preferable has all my bugs fixed :-) ] Do you have any
   information when your patch will be included? Cheers, Norbert
   P.Marek <pmarek_at_cpan.org>
   Date: 2003-06-12 12:43:02 CEST
   "I posted a patch which did some things but didn't some other;
   most notably, the saving of timestamps on commit was missing.
   But the solution for that problem gave me some problems.
   (1) - A property update on commit, but the local property file
   may be empty, so some io_read_-function (can't remember the
   name right now) died (2) - "svn status" says that properties
   have been modified, as I have to fake the mtime for files
   which don't have this property. (3) - I thought that the best
   way to handle this behaviour would be to only overwrite
   existing mtime-properties on commit. So everyone using svn on
   older repositories would continue as before, and new imported
   (or added) files would be tracked. (4) - I got a bit lost
   while trying to find a good interface for seperating the
   os-specific properties (executable, acls, access rights, ...).
   The problem is that I found too many places where these
   things are handled - so a function which could insert all
   os-specifics into a apr_table couldn't handle a apr_hash
   and so on - but different types are used in different places,
   so there would have to be a multitude of handling functions.
   For the first two problems I experimented some time by
   changing to entry-properties (which are remembered in the
   Entries-file instead of the /propbase/-directory, but that
   made things worse, as these properties are AFAIK not saved
   in the repository. So as I'm thinking of something the last
   patch is still current - it takes the data on add and import
   and uses it on export (not update, due to the dependencies
   problem). I'm still thinking about a good solution for the
   commit problem regarding m-time. (currently leaving all
   other os-specific properties aside). But I could not find
   one yet. Any help is appreciated :-)
   Norbert Gruener <nog_at_MPA-Garching.MPG.DE> !!++
   Date: 2003-06-17 13:42:19 CEST
  "[[I believe it will have to be completed before - I still
  experience some problems.]] "I see. That means, this is
  nothing which will come in the near future. [[I posted a
  patch which did some things but didn't some other; most
  notably, the saving of timestamps on commit was missing.]]
  Does that mean that SVN did not save the old timestamps
  somewhere in the background and all the old timestamps are
  lost? This is not a very encouraging answer :-( This will
  give me a hard time to convince the CVS users at my site
  to convert to SVN. I know that this was not your decision
  and I am not blaming you. Just on the contrary I want to
  thank you that you are working on this feature. Cheers,
   From: P.Marek <pmarek_at_cpan.org>
   Date: 2003-06-18 07:24:57 CEST
   "Well, the support for add/import/export is there. I'll
   just have to find a way to ship the mtimes on commit...
   Well, AFAIK (from "svnadmin dump"), only the commit-time
   is saved, not the individual timestamps. But that is to
   change in the future :-) ... I'll try to get commit
   working, maybe in an (internal) ugly way. Do you want
   to beta-test a patch if it's ready??
   Norbert Gruener <nog_at_MPA-Garching.MPG.DE>
   Date: 2003-06-20 07:16:33 CEST
   "Yes, I would be happy to help you by testing your patches.
   So as soon as you have anything to test, just let me know.
   At the moment I am running subversion release 0.23.0.

saving files' time stamps
   From: P.Marek <pmarek_at_users.sourceforge.net>
   Date: 2003-06-18 11:38:00 CEST
   "Hello everyone, it's me again. Now I've got a patch
   against 0.23.0 which saves the timestamps on add, import
   and commit, and restores these on export (but not update).
   "make check" failes on 3 tests (see attachment), which
   is because of two issues: 1) "svn status -u" gives
   property modified ("xM ...") 2) "svn diff -r x:y" gives
   a property diff. I seem to be unable to find the point
   where I can change 1, and I'm not sure if I should change
   2. As of now I believe there should be a sub-class of
   "svn:"-properties, which are called "volatile" in the code,
   and which hold the os-specific properties - that would
   be svn:executable, svn:text-time, svn:acl (when we've got
   these), and so on. But I'd like to get some feedback first.
   I'll now try to upgrade this to 0.24.1; if there are no
   other comments I'll change "diff" to not show the volatile
   properties. Any help appreciated :-)
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-06-19 16:11:39 CEST
   "Hi Philipp,

   Sorry that nobody's been giving you feedback here... we've
   all been pretty busy! I'm glad you're working on this issue.

   Timestamp-preservation is a complex feature, just like
   eol-translation and keywords (which tooks us *weeks* to
   write and debug). I think it needs a lot of design discussion.
   Previous list threads on this topic haven't gone very far and
   gotten a bit muddled... and so now I'm worried that you're
   off in the corner, writing huge patches, but getting no
   developer feedback as to whether you're moving in the
   "correct" direction or not.

   So I'd like to talk about this feature some more, if you don't
   mind. Here I am. :-) [...]

   Yeah, I don't think the idea of "volatile" properties is
   gonna fly. Properties that users can manipulate (via 'svn
   propset') are normal, versioned things. It sounds like you
   want *unversioned* metadata attached to each file... and we
   already have a mechanism for that. We call them "entry" props,
   and they live in the .svn/entries file. They're marshalled
   over the network (from server to client only) with the
   svn:entry: prefix, then stashed in .svn/entries. The user
   never sees them, unless they run 'svn info' on a file. For
   example, many of the values that get expanded into keywords
   (changed rev, changed date, author) are "entry" props.

   A random tip: this project has a lot of coding practices and
   policies, all documented in our HACKING file. It's pretty
   hard to get people to review large patches if you don't supply
   a detailed log message that orients the reviewer to the "big
   picture." Your latest patch has no log message at all. Your
   earlier patch is just a list of files, followed by two
   sentences of feature description. Try running 'svn log' on
   svn's own tree, to see the level of detail HACKING requires. :-)

   That said... I'm going to start a new mail thread in just a
   second, so we can work out a nitty-gritty detailed design.

timestamp preservation design (issue 1256)
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-06-19 17:37:29 CEST
   [** First in sequence/thread with 59 postings]
   "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: ...
   Ghudson has pointed out that two different designs have been
   bantered around for making the svn client "set timestamps".
   Here they are... 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?... [** see details in the text**]
   Jack Repenning <jrepenning_at_collab.net>
   Date: 2003-06-19 17:59:51 CEST
   ".... Clock skew is a problem for either approach, because it
   redefines what a time actually means. The complex approach
   provides more points of confusion, but not really any more
   failure modes: the solution must be to keep all systems in
   sync, either way you slice it. On the other hand, clock skew
   is *not* a problem for either approach, because anyone asking
   for timestamp preservation already understands this, and
   has heard of NTP... What's left to explore is the use cases
   that create the request in the first place (the question
   that comes before every question).
   Michael Price <michael.price_at_computer.org>
   Date: 2003-06-19 18:01:58 CEST
   "The attached file shows what CVS currently does. As for subversion,
   I can live with the current behavior or the simple behavior
   but don't really like the complex behavior. The current behavior
   with a switch for simple behavior would be nice...
   "Forgot to mention... apparently updates just set everything to
   the current time, regardless of which revision you are updating to.
   Wacky. Lets not go out of our way to mimic cvs. Michael
   Max Bowsher <maxb_at_ukf.net>
   Date: 2003-06-19 19:55:08 CEST
   "Not wacky. There is a reason for this - most of the time, it
   causes make to function correctly."
   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
    Jack Repenning <jrepenning_at_collab.net> !!++
    Date: 2003-06-19 21:41:31 CEST
    [[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.]] "Well, what
    is their relationship, and whether that's useful, depends
    on a lot of assumptions about the surrounding process. It's
    not useful for "the ghudson use case," but some people
    really get addicted to its peculiarities. [[I think the
    complex approach has value, because then you can:...]]
    "Yes, I agree that this is an interesting use case."
   [** long posting, summarizes P's work to date **]

   Branko <brane_at_xbc.nu>
   Date: 2003-06-20 09:41:34 CEST
   [[A versioning system is about *conserving* information,
   not losing it. Ideally *all* file information should be saved]]
   "Heh. What happens to ACLs if you commit on NT and check out
   on Unix? What happens to Unix rights if the committer is
   'root' but 'luser' wants to check out a setuid file? There
   are probably hundreds of such interop problems with this
   idea, which is mainly why we didn't implement it (yes,
   we _did_ discuss it). Conserving information is not the
   same as being a cross between a magpie and a packrat.
   Some things are better forgotten. :-)"
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-06-24 16:46:32 CEST
   "So for these reasons, I think {Ben, Karl, Justin}
   are of the opinion that if we have a timestamp feature
   at all, the CVS behavior is probably the least evil of
   all options, and most useful.
   Robert Pluim <rpluim_at_bigfoot.com> !!++
   Date: 2003-06-24 19:29:09 CEST
   "So you don't want time-stamp preservation on export either?
   I personally don't care, but I can quite easily see that
   some people might, especially if they're checking generated
   sources into their repository. Robert Footnotes: We can have
   a discussion on the relative evilness of that some other
   time ;-)
   Karl <kfogel_at_collab.net>
   Date: 2003-06-24 18:42:44 CEST
   Ben Collins-Sussman writes: [[So for these reasons,
   I think {Ben, Karl, Justin} are of the opinion that
   if we have a timestamp feature at all, the CVS behavior is
   probably the least evil of all options, and most useful.]]
   Yah. Plus the no-surprises factor if we just do what CVS does.
   Philip Martin <philip_at_codematters.co.uk> !!++
   Date: 2003-06-24 21:48:32 CEST
   "I tend to agree with Greg here, I don't really like
   the CVS behaviour (but then I'm not a CVS user). If
   we are going to go to all the trouble of storing and
   retrieving commit times it seems odd to do it only for
   CVS compatibility. Assuming someone gets as far as
   implementing a system to save/restore timestamps, then
   I'd much rather see a config/option setting that
   controls the behaviour. I'd like to be able to select
   the current behaviour, and I also like to be able to
   select full timestamps. Full timestamp behaviour would
   set the timestamps to the stored timestamps for checkout,
   update, revert, export, URL->wc copy (WC->WC copy as
   well?) and merge, with the proviso that an update that
   modifies a file with local modifications, and a merge
   that modifies existing files, should use now rather
   than the stored timestamp.
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-06-24 19:54:56 CEST
   "None of my proposals have been about storing any new
   information. I don't want to implement any new systems
   to save/restore timestamps. We already have commit-times
   coming back from the server, and embedded in entries
   files. My proposals have simply been a matter of "hey,
   why not use them once in a while, for something other
   than keyword expansion." Very, very simple.
   John Peacock <jpeacock_at_rowman.com> !!++
   Date: 2003-06-24 22:58:29 CEST
   "A little light just went on in my head on the subtleties
   with the interaction between versioned source files and
   derived files. I'm still more interested in not losing
   the timestamp information, but I can now see how it
   likely to be very difficult to get it 100% right."
   P.Marek <pmarek_at_users.sourceforge.net>
   Date: 2003-06-26 07:42:11 CEST
   "As I learned that svn doesn't do timestamps (which I
   require), I set out to implement them. I know that the
   decision is not easy - but I got some responses telling
   me that mtime restoration is needed not only by me.
   So I'm perfectly happy if the default behaviour is to
   mimic CVS; but I need something to give consistent
   snapshots with at least mtimes to other people.
   My question is now - if the current implemented behaviour
   - ie. restoration on export, saving on import, add,
   commit, a "hidden" svn property - is given to you as
   a patch, remarks included, no changes to the "update"
   functionality (apart from hiding the property) --
   are there any wishes, remarks, comments, etc., or
   is there at least a 50:50 chance that someone looks
   at the patch? Please, please! |-\
   David Mankin <mankin_at_ants.com> !!++
   Date: 2003-06-21 08:58:39 CEST
   [[now ... 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.)..]]
   "(First I present motivating use-cases, then Two principles to
   which they lead.)

   I'm going to have to argue against the status quo approach
   here, at least for "simple" users. All of the discussion of
   what's right for a build system only takes into account
   the times when Subversion is used as a *source code*
   versioning system. We've seen many use cases discussed on
   the mailing list of people who are (going to be) using SVN
   for things that aren't source code. People who are not
   dealing with build systems don't care that the timestamps
   of a recently svn-updated or checked-out Word document
   should be newer than a locally modified PowerPoint. Instead,
   they want to know (by looking at the filesystem) how old
   the Word document is. With the status quo, a new checkout
   has all the files dated Today, and none dated February, no
   matter how old they are. Without timestamp preservation,
   svn may be able to replace CVS, but it won't be able to
   replace the dreaded shared folder on a file server for these

   Also, when a file is copied out of a working copy,
   modification date is the only versioning metadata that is
   kept with it. (Non source-code files often aren't text
   format and so can't be labeled with a $Version$ tag.) If
   I copy a gif file from my computer to the web server, I
   only have timestamp to tell me which version is deployed.
   If someone else's working copy has different timestamps
   for the same version of the image, they will think it's
   not the same version of the file. The same problem will
   happen if I re-checkout and the timestamps change. This
   can lead to unnecessary file uploads (especially if my
   ftp client is timestamp sensitive, but isn't rsync), which
   leads to unnecessary timestamp changes on the server,
   which leads to images being re-downloaded by all clients.

   Two principles. If I choose the "timestamp preserving" option
   for my working copy:

   1) Timestamp handling should be easy to explain: The timestamp
   of a file should always approximate the date it was last
   modified. (I don't care much whether it's the date it was
   actually last touched, or the date it was committed --
   assuming that for the most common use cases the two will
   be similar.)

   2) Checkouts and updates should be interchangeable. (If I
   have no local mods, why should I have different semantics
   (timestamps) if I throw away my working copy and checkout
   again.) This implies not setting the timestamp to something
   different based on the subcommand (co, up, export) used.

   I'm not saying that timestamp preservation is right for
   everyone, but it certainly should be an option for those
   for whom it is. [UI discussion postponed.] -David Mankin

timestamps, take N+1
   [*** Important summary vis-a-vis 59-message-thread above ***]
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-07-03 04:12:34 CEST
   "Some folks want svn to have a complete mtime preservation
   system. Some folks don't like this idea. But either way,
   it involves creating new property types, new marshalling,
   and from what I can tell, is generally way too complex to
   just "throw into" svn 1.0."
   P.Marek <pmarek_at_users.sourceforge.net> !!++
   Date: 2003-07-03 07:09:34 CEST
   "That ok for now. But it won't meet my criteria. I need
   to have the *original* timestamps versioned, as they are
   the most acknowledged attribute I have to differenciate
   between versions (the external source's versions, not my
   svn-internal) It's fine with me if that's used now in svn
   - but if you want to have the files' mtime instead of
   commit-times there'll have to be a new property (and
   maybe property class), which has to be special cased in
   some functions, ... So I believe that most of the code
   needed comes from this one change - use mtime instead of
   commit-time. Time will show ..."

RE: saving files' time stamps
   Paul <pll_at_lanminds.com>
   Date: 2003-07-03 18:47:38 CEST
   [[I've got a patch against 0.23.0 which saves the
   timestamps on add, import and commit, and restores
   these on export (but not update).]]
   Filed as Issue 1391:
   Seeya, Paul [Paul Lussier]
   [[pll_at_tigris.org - Apparently a duplicate of 1256,
     possibly even 1112. This issue has been marked as a
     duplicate of 1256]]

svn, cvs, and timestamps
    Michael Price <mprice_at_atl.lmco.com>
    Date: 2003-07-11 19:20:38 CEST
    "I don't know if this came up in the last thread on svn
    and timestamps, but I just noticed this comment in the
    NEWS file in the latest CVS tarball: * 'When a file is
    initially checked out, its last access time is now set
    to the current time rather than being set to the time
    the file was last checked in like the modification time
    is. So I don't know what the consensus was on svn
    and timestamps but I figured people would be interested
    in CVS changing part of its stance on the issue. Michael

timestamp stuff, issue 1445
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-09-05 00:54:30 CEST
   "I'm trying to finish 0.30 issues, and #1445 talks about 'svn
   export' and 'svn checkout' setting last-commit-timestamps on files.
   I don't want to repeat the huge conversation we had on this list
   about how timestamps should work; rather, I just want to
   affirm the short-term strategy for 1.0. Here's what I remember:
   * Everyone agreed that 'svn export' should set last-commit-times
     on files. That feature was already committed a while back;
     we're simply waiting for httpd-2.0.48 to be released
     (to get the new APR timestamp-setting API).
   * At least one person had a proposal to write a fancy system
     for storing and retrieving mtimes; this was deemed too complex
     for 1.0, and put off for discussion as a post-1.0 feature...
   In summary, once I commit this change, the behavior will be:
   * 'svn export' always sets commit-times
   * 'svn update' always sets now-times
   * 'svn checkout' can behave either way, based on config variable.
   "Oh frell. I got the proposal wrong again, misunderstanding ghudson.
   So my actual proposal is this:
   * 'svn export' always sets commit-times
   * 'svn update/checkout' uses either commit-times *or* now-time
      based on config variable.

SVN import behavior and save/restore of file timestamps
   Charles E. Doucette <cdoucette_at_med-learn.com> !!++
   Date: 2003-11-07 17:40:57 CET
   "I was just helping a colleague who wanted to put a project under
   source control...Unfortunately, I informed him that every single
   file and directory would reflect the current date and time and not
   the original date and time (and therefore the diff may
   fail or appear to fail). I can accept that saving/restoring
   timestamps may not be a critically important feature for
   1.0; but, I believe *very* strongly in it so I certainly
   hope it will be implemented eventually and ideally very soon
   after 1.0 is released. His plans to put this project under
   source control are put off at least for now because the
   file timestamps aren't maintained. This effectively loses
   history and makes it harder to see what might have changed when.
   Charles E. Doucette <cdoucette_at_med-learn.com>
   Date: 2003-11-11 23:06:35 CET
   "I was hoping to get a response to my post; so, perhaps if I
   phrase it in the form of a question I might get a response?
      1. Is the current behavior of the SVN import command equivalent
         to the CVS import command (i.e. it doesn't put the current
         directory under source code control)?
      2. Is there a plan to save/restore file/directory (modification)
         timestamps - perhaps as built-in SVN properties? If so,
         approximately when is it scheduled (i.e. post 1.0)?
   Thanks, Chuck
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2003-11-11 23:22:28 CET
   "[Is there a plan to save/restore file/directory (modification)
   timestamps - perhaps as built-in SVN properties? If so,
   approximately when is it scheduled (i.e. post 1.0)?]
   There is no plan, but it's been discussed before.
   Right now, we have a runtime option to make files always
   have their timestamps set to the 'last commit time' in
   the repository. But we haven't scheduled a timestamp-preservation

[11] ======== Postings from 2004 ========

Don't need commit-times, now-times. Needed only real create/modify times.
    Slava Kostin <sk_home_at_mail333.com> !!++
    Date: 2004-01-17 11:48:33 CET
    "I understand, this means that there's only two behaviours
    possible - setting commit times ("yes") or setting now times ("no").
    But I really need to save file creation/modification times
    unchanged. Can I somehow do this?"
    Jan Hendrik <jan.hendrik_at_bigfoot.com>
    Date: 2004-01-17 12:38:30 CET
    "AFAIK this is not possible so far. However, the file's timestamp
    is not changed by SVN on commit. It is just that on a
    checkout/update of other or new working copies files then
    either get the timestamp of last commit or current time."
    Jan Evert van Grootheest <j.grootheest_at_euronext.nl>
    Date: 2004-01-19 09:39:36 CET
    "[However, the file's timestamp is not changed by SVN on
    commit.] Jan, I'm not sure you are correct. I think that if you
    use keywords, [working copy] files are updated during commit
    (and thus the times change). At least my editor notices that
    the file has changed and asks me what to do with it. But,
    obviously, that only goes for files that have the svn:keywords
    property set."
    Jan Hendrik <jan.hendrik_at_bigfoot.com>
    Date: 2004-01-19 15:37:33 CET
    "you surely are right. Haven't thought of keywords (no
    experience so far with them), but given SVN's policy not to
    change files after commit they must indeed be set/changed in
    the working copy before."

Import, timestamp
   Aladar Nagy <a.nagy_at_interton.de> !!++
   Date: 2004-04-01 15:55:04 CEST
   "How can i import a new project (files) with the original
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2004-04-01 18:27:56 CEST
   "You can't. Subversion doesn't preserve timestamps or
   permissions, other than 'executable'). However, you can
   make the working copy files always have the "last committed"
   timestamp by setting an option in your run-time config file."
   Jan Hendrik <jan.hendrik_at_bigfoot.com> !!++
   Date: 2004-04-02 10:40:56 CEST
   "Work around: Just create your repository and import just
   your basic folder layout (e.g. /trunk, /branches/, /tags)
   and check it out to a working copy. Now copy all your
   files into that working copy and add/commit. That's how
   I did it with a web site project for I needed to have the
   dates preserved because of the upload routine. Jan hendrik

Any way to specify Date/Time on commits?
   Greg Goodrich <ggoodrich_at_medinotes.com> !!++
   Date: 2004-05-06 19:33:20 CEST
   "I'm trying to convert from MS Visual SourceSafe to Subversion.
    One of the problems I'm noticing is that once I get all the
    historical revs from VSS to Subversion, they all (of course)
    have the date/time that I committed them into Subversion.
    I'd really like to preserve that information and was wondering
    if there is a way to get these dates/times altered (maybe a
    hidden switch to svn commit?). I can redo the migration, as
    I've got to anyhow, but I just would like a way to do this
    if it exists."
    Ben Collins-Sussman <sussman_at_collab.net>
    Date: 2004-05-06 19:39:01 CEST
    "Certainly. Every revision has a set of unversioned properties
    attached to it. Here's an example: [...] You want to manually
    'propedit' the svn:date property on each revision. But you
    don't say *how* you're converting from VSS to Subversion. If
    you're using some tool to do this, it should automatically
    be doing this for you. (e.g. if it's creating the commits in
    the form of an svn dumpfile, like cvs2svn.py does, then the
    dumpfile would automatically contain the correct svn:date
    Greg Goodrich <ggoodrich_at_medinotes.com>
    Date: 2004-05-06 20:48:09 CEST
    "using a script called "migrate.pl" that is for converting
    from vss to svn, though I've fixed a few "bugs" in it
    already. It actually commits changes one rev at a time from
    each file in vss to svn. I'll have to check to see if it
    is attempting to set this property

timestamp Problem
    Andreas <e-mail_at_andreas-otto.de> !!++
    Date: 2004-07-07 23:09:47 CEST
    "I have the Problem that the timestamp of the files I check
    out is not the same compared with the source files. What
    do I have to do to change to solve this? Greetings, Andreas
    Ben Collins-Sussman <sussman_at_collab.net>
    Date: 2004-07-07 23:20:24 CEST
    "Subversion doesn't preserve timestamps. But if you wish,
    it can make your working-copy timestamps reflect the last
    time each file was changed in the *repository*." Set the
    "use-commit-times" variable to "yes" in your client's
    run-time 'config' file.

RE: Re: preserve modification date on co?
    Charles Doucette <charles.doucette_at_synxis.com>
    Date: 2004-09-09 22:13:09 CEST
    "Preserving modification date/time (not commit date/time) is
    one of my hot button issues. It's one of my few beefs against
    Subversion. I agree permission/ownership/ACLs aren't portable.
    I believe modification times are portable. I don't know
    exactly what CVS does with file modification times
    (whether they are maintained). At least Visual Source Safe
    has the following option: Set date/time on local files:
    Current/Modification/Check-in. The configuration option
    "use-commit-times=yes" is equivalent to the "Check-in"
    value above.

    There are at least two problems with not saving (and giving
    the option to restore) modification time as meta data:
    1) Information (when the file was last modified) is lost
    2) It makes it more difficult to compare files and directories

    Putting something under Subversion source control should ideally
    not have to modify it at all - just make a copy of each file
    and directory and then keep track of the changes from that point
    on. Giving people options as to what date/time to set on a
    file for check-out and can either preserve/restore information
    (the last modification or check-in time) or it can be set to
    the current time to force a rebuild with that file. I hope this
    feature (to save/restore file modification times as built-in
    meta data) will be added to a future version of Subversion.
    Thanks, Chuck
    Lee Merrill <LeeMerrill_at_bustech.com>
    Date: 2004-09-09 22:25:51 CEST
    "Hi everyone, But I think "check-in time" is virtually
    the same as modification time, though. The user could have
    modified the file 1 second before committing it, or 100
    seconds, but I don't see why this history needs to be
    preserved. Especially for users checking out these changes,
    that history is unimportant, and "check-in time" is all
    that is needed, as far as I can tell. I'm not sure what
    you mean about modification time being beneficial in
    comparing files and directories, though, it seems diff is
    what you really want to use, and if the timestamps differ,
    it still doesn't matter... Lee
    Charles Doucette <charles.doucette_at_synxis.com> !!++
    Date: 2004-09-09 22:40:54 CEST
    "First, I was thinking about the initial import into
    Subversion. It is nice to preserve the initial modification
    times. It's important meta information and belies the
    history of the file outside of Subversion. Although you
    may be right that you commit a file soon after you modify
    it, what if you are modifying a group of files - and they
    all must work together before you do a commit. You may
    edit the first file on a Monday, and the last file on a
    Friday, and then do a commit. It would be nice to
    save/restore that information to differentiate between
    when the file was last edited and when it was last
    Steve Greenland <steveg_at_lsli.com>
    Date: 2004-09-09 23:12:19 CEST
    "I suspect that it comes from working w/o a version
    control system, and mod times are the only way you have
    of tracking such things. But they're so damn unreliable.
    Once I got used to having a VCS, I completely lost
    interest in filesystem timestamps - the VCS provides
    much more useful info. All IMHO, YMMV, etc. etc. etc.

Re: preserve modification date on co?
    Ben Collins-Sussman <sussman_at_collab.net>
    Date: 2004-09-09 20:21:18 CEST
    "[[Destroying information without need doesn't seem very
    unix-like to me.]] "Subversion is not designed to "create
    a perfect snapshot of every bit of data and metadata that
    can possibly exist". It versions pathnames and directory
    contents. It also versions metadata, but only metadata
    that *it* considers relevant: the last time a file was
    committed, by whom, and so on. It makes no promises
    that its own metadata will conceivably cover and capture
    every bit of metadata in existence on every filesystem

Re: svn - saving time stamps of files - your posts 05/2003
    Ph. Marek <philipp.marek_at_bmlv.gv.at>
    Date: 2004-10-15 10:44:29 CEST - Thomas Wies
    [[On Thursday 14 October 2004 18:39,
    <wies_at_wiessoft.de> wrote: !!++
    'i found your posts on tigris.org when i looked for a SVN
    option like cvs -M to preserve the original file date.
    Unfortunately there is no solution to this problem - using
    commit dates is not really useful when importing existing
    (old) projects into subversion. Did you improve/finish
    your patch? Do you have a diff against current svn 1.1.0?
    Would you share this patch with me? I have just started
    testing subversion and this timestamp issue is IMHO a design
    flaw. Not the svn developers should decide how timestamps
    are handled but the user.]]

    I've done a try with 1.1.0; the patch merged mostly as-is,
    but it doesn't work. I've had a quick look into the source,
    but it seems that the setting of the commit-date gets in
    the way.' So there is currently no available patch. Question
    to the list: Has possibly someone ported my old patch to
    the current tree ? (that is, 1.1.0 or 1.1.1?) I propose the
    following behaviour:
     - on export the svn:text-time or, if not available,
       commit-time is taken as mtime of the file.
     - on commit the svn:text-time is updated, if the file
       currently has a property svn:text-time.
     - for update and add a command-line-parameter like
       '--save-file-time' tells svn to apply resp. save
       the files' mtime.
    If this option can be saved in some kind of
    ~/.svnrc (like ~/.cvsrc) it would be heaven ... :-) I won't
    be able to start my work on this for the next time - maybe in
    november. So please, can someone beat me to it ? :-) As far
    as I've looked it's much easier than with 0.24, as the funtions
    for querying and setting the mtime are already in apr.

saving time stamps of files with subversion 1.1.1
    Ph. Marek <philipp.marek_at_bmlv.gv.at>
    Date: 2004-11-04 09:24:36 CET
    "Hello everybody, here's an updated patch for subversion
    1.1.1 which allows subversion to save and restore the
    file's modification time. This was previously documented
    in issue 1256
    - What this patch *should* do On an import/commit, if a
    file has the "svn:text-time"-property set (to _any_ value),
    it gets the file's current mtime set in this property, as
    a svn-timestring (yyyy-mm-ddThh:mm:ss.uuuuuuZ). On
    update/checkout/export, if a file has this property set
    *and* the configuration "use-commit-times" is set, the
    file's specific property overrides the commit-date.
    - Beware! This is just a test-patch. I believe it does
    what I tell above, but may have bugs! It surely is ugly
    - that is partly because I'm not really familiar with the
    subversion code base, and partly (as other developers say)
    because the libsvn_wc code is ugly, too :-) I've included
    some people who expressed interest on this feature as a
    bcc: - I hope that's ok. Please give me comments - better
    patches etc. welcome. Regards, Phil
    Julian Foad <julianfoad_at_btopenworld.com> !!++
    Date: 2004-11-04 14:25:40 CET
    "Certainly I think the ability to save and restore a
    file's mtime is useful. I'm not sure if a normal file
    property is the right place to store the time - it seems
    very odd to have a property that the user can modify but
    Subversion will always overwrite any value that the user
    puts in it. One question (I haven't tested this patch to
    try to find the answer): when you modify the property
    during a commit, do you also modify the text-base version
    of that property and the working version of it? Please
    write a log message, in the style described in the
    HACKING file. I'm sorry I don't have time to review the
    code functionally at the moment, but I am interested so
    I will try to do so soon. For now, I will just say: please
    pay attention to the formatting of the source code. Try
    to set up your editor to help you with this. If you use
    vi(m) or emacs, use the configuration files available
    in tools/dev/svn-dev.{el,vim} in the Subversion source
    tree. Don't use tab characters for indentation; don't put
    a space after an open parenthesis or before a close
    parenthesis; put spaces around operators, including "=";
    when a parenthesised expression is continued onto the
    next line, continue it from the column just after the
    open parenthesis. Thanks. - Julian
    Ph. Marek <philipp.marek_at_bmlv.gv.at>
    Date: 2004-11-04 14:52:15 CET
    "I believe that is just a matter of documentation -
    after all, it's immensely useful to do a svn ps
    svn:text-time "2004-01-01T02:03:04.000000Z" <URL>
    and have the file the correct time someone updates
    .... [...] Well, it better should be done locally too
    - that's why there is a SVN_ERR (svn_wc_prop_set
    (SVN_PROP_TEXT_TIME, propval, path, adm_access, pool) );
    in the patch. [...] Thank you very much! Of course if
    there's someone of the core developers interested I'll
    likely put more effort into this, eg. write a log
    message :-) As long as I'm the only user it seemed not
    worth the time - especially because a log message has
    to include the function names, and I don't know an
    automated way to generate that (haven't read HACKING
    yet, though) [...] I tried to follow the indentation
    - but if there's a config file for vi I'll use that
    next time. The indentation is the least of my worries :-)
    Thank you for your time! Regards, Phil
   Julian Foad <julianfoad_at_btopenworld.com>
   Date: 2004-11-04 15:32:19 CET
   "Well, I'm interested, and I'm a developer with commit
   access; not one of the most active ones who you would call
   the "core", but I could commit your patch... It is worth
   the time, because people will find it easier to review
   your patch if they can read the log message first, and
   therefore people will be more likely to review your patch
   and take an interest. To get the function names
   automatically, try my attached script "svnlogmsg", which
   generates a log message template, including the file
   names and function names, with a diff below, ready for
   you to fill in the details...

[PATCH] saving timestamps as properties
   Ph. Marek <philipp.marek_at_bmlv.gv.at>
   Date: 2004-11-09 07:18:33 CET
   "Hello Julian, hello everybody else, here's the 2nd
   version of my patch. The functionality has not
   changed, I have only fixed the formatting and wrote
   a log-message. Also attached is a documentation update;
   but that's just a discussion starter, as I'm not a
   native english speaker and it may be much more readable
   if written in other words. Regards, Phil
   * text/x-diff attachment: patch-tstamp-svn1.1.1-2.patch
   * text/x-diff attachment: patch-tstamp-svn1.1.1-doc-2.patch
  [regression test failure]

Export without last-commit timestamp
   Stephen Downs <steve_at_plasticbrain.com> !!++
   Date: 2004-11-28 19:59:16 CET
   "I'd like to use Subversion export without imposing a
   last-commit timestamp on all exported files. Is this possible?
   I need to maintain modification dates on my files and export
   a clean directory of the project without the .svn data for
   use in builds. The files end up in an InstallShield
   updater-style project which relies on file modification dates
   to determine if files need to be installed or not. Using svn
   export, all files are marked with last-commit timestamps
   which are later than the modification date of the files,
   erroneously resulting in every file being replaced by the
   installer in the case where a user has a previous version
   installed. Instead of using svn export I've been duplicating
   my working copy, then removing each instance of the .svn
   folder by hand.
   "No, that would give him the date/time of the export, not what
    he wants. What he seems to want is the file modification
    time to be store in Subversion on a commit, and have export
    set that time on the file after it exports it. There are
    some patches floating around for this, but otherwise, the
    answer is that Subversion does not do it."

subversion timestamp issues
    Jim Van Zandt <jrv_at_mitre.org> !!++
    Date: 2004-12-23 16:11:30 CET
    "Tom Rawson wrote: 'when I check out a file I want it to
    have the same filesystem timestamp it had when I
    committed that revision.' Patrick Smears replied:
    'The reason for the default behaviour is that any
    other behaviour tends to confuse utilities like 'make'
    that depend on timestamps on files to determine which
    file has been changed most recently.' Scott Palmer wrote:
    'The option to preserve true modification time should be
    available. (And preferrably built-in, not up to some wrapper
    script hacking.' -- I agree with all of the above. I
    suggest that subversion should implement both behaviors.
    The default for "svn checkout" should be to keep the
    timestamp when last edited. The default for "svn update"
    should be to use the current time. - Jim Van Zandt.

[12] ======== Postings from 2005 ========

file date in the repository
    Michael <MDidschuns_at_medistar.de> !!++
    Date: 2005-01-17 18:08:51 CET
    "Hello, my problem is to either import files in to the
    repository with the dates of the files intact or change
    the svn:date later. Since I found no way to import the
    files with the date intact, I thougth that I could use
    the command 'svn propset svn:date ...' to modify the
    date in the repository. This seemd to work fine. But now,
    when I try to verify the repository is get the error
    message 'svn: Bogus date' on 'old revisions. My suspicion
    is that this was caused by my actions. Can someone
    confirm this and/or tell me how I can get the files date
    in to the repository? Thanks, Michael
    Peter Valdemar Mørch <nospam_at_morch.com> !!++
    Date: 2005-01-17 22:24:52 CET
    "I'm not sure what you're trying to accomplish, but I
    believe the client will always modify the date of flies
    when checking them out to be the current date/time,
    regardless of the date it had when checked in. There
    have been numerous threads about this in the past. The
    "winning side"'s argument is that newly checked out files
    need to be timestamped "now" regardless of when they really
    were created, because otherwise make systems (the assumed
    most common usage) get confused. The "loosing side"'s
    arguments, well, who can remember them? :-D So if you are
    trying to get a checked out file to have the same date
    as when it got checked in, I think you may be fighting a
    losing battle here... I'm not sure what to search for,
    but there have been threads in the past about this.
    (If that is what you're trying to do.) Peter
    Marius Gedminas <mgedmin_at_b4net.lt>
    Date: 2005-01-17 23:09:54 CET
    "There's also: [miscellany]... use-commit-times = yes
    in ~/.subversion/config. And it does confuse make, as
    I've had the chance to discover today. ;-) Marius Gedminas
    Scott Palmer <scott.palmer_at_2connected.org> !!++
    Date: 2005-01-18 16:05:54 CET
    "[The "losing side"'s arguments, well, who can remember them? :-D]
    I've argued the point before, as have several others. I don't
    recall 'losing' as much as the Subversion developer's
    simply wouldn't acknowledge the point - claiming (with an
    amazing bit of ridiculous circular reasoning) that timestamps
    shouldn't be relied on because some things don't preserve
    them, so Subversion isn't going to preserve them.

    I find it odd that the argument against preserving important
    meta data comes down to the fact that a build tool such as
    make can get confused, so everyone must suffer to make up for it.
    A simple option to preserve the timestamp using a property much
    like svn:executable makes sense. Btw, sv:executable seems to
    always do the wrong thing on Windows which doesn't have an
    executable property in the native file system resulting in
    svn:executable being set for every file.

    The lack of this feature seems short sighted.. For similar
    reasons as 'make' needs to have the timestamp bumped, other
    tools might want it preserved. There is a reason that all
    modern filesystems store such meta data! You implemented
    preserving of the 'executable' property that isn't even
    stored by some of the filesystems that Subversion runs on.
    Surely there is some justification for preserving properties
    that are common to all the filesystems. Is there an
    existing feature request for something along the lines of
    svn:date or svn:modtime? Scott.
    Dale Worley <dworley_at_pingtel.com> !!++
    Date: 2005-01-18 16:53:25 CET
    "[[claiming (with an amazing bit of ridiculous circular
    reasoning) that timestamps shouldn't be relied on because some
    things don't preserve them, so Subversion isn't going to
    preserve them.]] More exactly, they live in a world where
    *many* things don't preserve timestamps, so nobody writes
    tools that rely on them. In that environment, getting
    Subversion to preserve timestamps gains the users little,
    because no tool depends on them. And if Subversion preserved
    timestamps, still nobody would write tools that depended on
    them. But there is another world -- a world where most
    tools preserve timestamps. And many tools depend on them.
    And you live in that world. Dale.
    Scott Palmer <scott_at_digital-rapids.com> !!++
    Date: 2005-01-18 17:51:05 CET
    "I guess it is true, I don't encounter many things that don't
    preserve timestamps. Other than the tools that modify the
    file in the first place, I copy the file from one place to
    another and the timestamp goes with it in all the cases that
    matter to me. Losing a timestamp is the exception to the rule.

    So back to the point, is there any reason that Subversion
    should support both worlds? I don't think anyone on the
    side of preserving timestamps is arguing against the fact
    that intentionally changing the timestamp has merit in many
    cases, such as not breaking 'make'. But that is quite clearly
    an intentional munging of the timestamp metadata for a
    particular purpose.

    It seems clear to me that "things that don't preserve
    timestamps" cause a problem that results in "nobody writes
    tools that rely on them". Given that the entire reason for
    not writing tools that rely on timestamps is because other
    tools messed up and didn't preserve them (which is sort of
    funny here, because one of the major arguments for modifying
    the timestamp is to be compatible with a tool, namely 'make',
    specifically because it relies on timestamps), it seems
    only logical that now that the problem is recognized the
    mistake would be avoided. Scott.
    Marius Gedminas <mgedmin_at_b4net.lt> !!++
    Date: 2005-01-19 23:50:56 CET
    [[ So back to the point, is there any reason that
    Subversion should support both worlds?]]
    Someone seems to be working on it:
    Marius Gedminas

What I need to do to have patch for Issue 1256 applied?
    Tardif, Sebastien <STARDIF_at_anacomp.com> !!++
    Date: 2005-02-18 20:41:36 CET
    Julian Foad <julianfoad_at_btopenworld.com>
    Date: 2005-02-18 21:03:36 CET
    "You need (or someone needs) to write a precise description
    of the required semantics of the feature - that is, what
    it does but not how it does it. The description must say
    what happens to the time stamp in all circumstances -
    including during "revert", during a WC-to-WC copy, etc.
    From: Julian Foad <julianfoad_at_btopenworld.com>
    2005-02-19 01:39:37 CET
    "Sorry, I did that a bit imprecisely (stripping the "What
    [do] I need to do...?" phrase which is still relevant) and
    a bit rudely. It wasn't aimed only at you, Sebastien. I
    just get a bit tired of seeing messages that require me to
    look up an issue number or a revision number in order to
    discover whether I'm interested in it, and I just happened
    to take this opportunity to point it out. The automatic
    commit mails are by far the biggest offender.

New feature request: commiting files with last mod times?
   Saulius Grazulis <grazulis_at_akl.lt> !!++
   Date: 2005-03-22 10:45:08 CET
   "SUGGESTION: What about introducing option into svn that says:
   "use last modification time upon commit and upon checkout"?
   The mod time could be stored as a property, perhaps. Ideally,
   this option should be bound to repository (but if this is
   too complicated, it could also be in the users' config files).
   OTHER BENEFITS: As a side benefit, this would also allow to
   import files without forgetting their true creation dates.
   This would help for the projects that started before putting
   them under Subversion, or for the projects that use files
   generated externally (for example, we use data files generated
   by measurement equipment, and data collection date is important
   parameter -- which is to some degree reflected by the file
   creation date). In a programming environment, I also see
   possible beefits of such feature. For example, when writing a
   heavily optimizing compiler, outputs of the compiler test
   runs are of interest for developers and might also be put
   under version control. Since such outputs will most probably
   generated by Make, the same problem would arise.
  "The only votes that really count are those cast by committers.
  However, we do pay attention to trends and try
  to accommodate things that are important to the users."

SVN revert maybe should not revert timestamp with use-commit-times enabled
   Adam Gibson <agibson_at_ptm.com> !!++
   Date: 2005-03-22 17:01:44 CET
   "I dont want to disable the timestamp feature because it
   is real handy to have an idea how old a checked out file
   is just by looking at the timestamp (other people without
   svn can get a general idea how old files are too).

Query regarding mtime versioning for 1.2 (issue 1256)
    Phil Marek <philipp.marek_at_bmlv.gv.at> !!++
    Date: 2005-03-22 14:36:14 CET
    "Hello everybody, as I see many requests for modification
    time versioning on (and off) this list I'd like to ask if
    that's a planned feature for 1.2. I'd consider the
    text-time -branch to be of enough quality (the other
    meta-data-branch should be looked at very hard by someone
    who really understands svn - that's still in beta) and
    often enough wanted to justify inclusion in svn.
    Julian Foad <julianfoad_at_btopenworld.com>
    Date: 2005-03-23 14:37:57 CET
    "It's not specifically scheduled to be in 1.2, but it could
    go in 1.2 if it is ready. Unfortunately, nobody else here
    knows exactly what the functional design of this feature is,
    so we don't consider it to be ready. If you want to get
    this accepted, perhaps you could persuade someone who is
    interested in this feature to write such a design proposal,
    and then we will be able to assess the proposal and test
    your implementation against it.

Feature proposal: maintain timestamps on svn hotcopy
    Scott Parkerson <scott.parkerson_at_gmail.com> !!++
    Date: 2005-03-23 21:47:07 CET
    "We currently do a full backup on Sunday, and incremental
    backups (based on what changed since Sunday) throughout
    the following week. The problem is that when I do I hotcopy
    of the repos, none of the original timestamps (ctime, mtime)
    are saved. This causes the incremental backup of the hotcopy
    to be the same as the full backup, which defeats the purpose
    of having an incremental/full backup routine in the first
    place. I've been going over the code in libsvn_subr/io.c and
    am considering modifying svn_io_copy_file to take an extra
    boolean flag (copy_times). By default, this behavior would
    be turned off on all callers of that function EXCEPT for the
    codepath that gets triggered when the user runs "svnadmin
    hotcopy --preserve-times", or somesuch. This would keep the
    code change impact down, as well. My questions are: a) when
    doing this patch, what do I need to look out for? and b) is
    there a reason this isn't done now (i.e. does it screw with
    assumptions made during design)? Furthermore, is there an
    existing unit test for this function, or is to me to come
    up with one?
    Philip Martin <philip_at_codematters.co.uk>
    Date: 2005-03-24 00:00:27 CET
    "You can't add a parameter to svn_io_copy_file as that would
    break the ABI. You need to rename the function, to
    svn_io_copy_file2 say, add the new parameter and implementation,
    and then write a wrapper with the original name and parameter
    list that calls the new function.... I don't think there is a
    specific test for svn_io_copy_file but the regression tests
    as whole exercise it. The hotcopy command gets run by
    subversion/tests/clients/cmdline/svnadmin_tests.py, you
    might like to add to that.
   Peter N. Lundblad <peter_at_famlundblad.se>
   Date: 2005-03-24 11:33:44 CET
   "The HACKING file is a good starter. Basically, you can't
   change the public API, but instead introduce new ones and
   deprecate the old. Check out the header file; search for
   @since and @deprecated to get the style we use. Thanks, //Peter

Re: Timestamp Frustrations/ FAQ update
    Phil <philipp.marek_at_bmlv.gv.at> !!++
    Date: 2005-06-05 10:12:47 CEST
    [[ 'trlists_at_clayst.com wrote: I am curious if anyone else has
    solved this problem. I asked about it many months ago and
    no one had.' ]] Please see:
    for the branch; see
    for patches against 1.2.0rc2 (which apply with a small fuzz
    also against the released version). As this comes up and up
    again, it should probably be at least listed in the FAQ (if
    it isn't taken into svn itself).

   James Berry <james_at_jberry.us> !!++
   Date: 2005-06-03 17:19:48 CEST
   "Sounds to me like maybe you just want rsync."
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2005-06-04 18:21:48 CEST
   "I understand your point, it makes sense. In other words, if
   subversion were versioning timestamps/owner/permission metadata,
   then that stuff would be preserved when porting changes, just
   the way file contents are preserved. Unfortunately, subversion
   doesn't version filesystem metadata. The current design is such
   that when you import files into the subversion repository,
   you're moving them to a new filesystem (the repository), and
   it then generates its *own* filesystem metadata:
   last-commit-time, last-author, last-changed-rev, filesize. This
   is all the stuff that 'svn ls -v URL' shows. All of the original
   metadata is lost. The working copy is just a disposable shadow
   of the 'real' filesystem, so you need to switch paradigms here.
   [uh, no]
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2005-06-03 16:34:13 CEST
   "I think what he really wants is the patch to preserve
   original filesystem metadata, such owner/timestamp/perms:
   Phil <philipp.marek_at_bmlv.gv.at>
   Date: 2005-06-05 10:12:47 CEST
   "Please see
   for the branch; see
   for patches against 1.2.0rc2 (which apply with a small fuzz also
   against the released version). As this comes up and up again, it
   should probably be at least listed in the FAQ (if it isn't taken
   into svn itself). Regards, Phil

Timestamp Frustrations
   Tom <trlists_at_clayst.com> !!++
   Date: 2005-06-03 15:13:23 CEST
   "I am curious if anyone else has solved this problem. I asked
   about it many months ago and no one had... The use of timestamps
   is embedded in my work style and practice in a number of ways,
   including simply looking at what I've changed lately, and
   routine copying of changed files between machines based on date.
   I attempted to write a wrapper script for the most common svn
   commands which properly handles setting a timestamp property
   for each file when it is added to or updated in the repository,
   then retrieving that and using touch to set the file time when
   the file is checked out. However this is incomplete at best
   (I keep discovering places where svn touches the files that I
   hadn't thought of, and having to reconstruct timestamp data),
   and it's cumbersome to maintain and use... in a single-developer
   environment sometimes this approach causes the loss of
   valuable information about the time the file was actually last
   modified. Has there been any thought to allowing svn to preserve
   the file timestamp which reflects the normal OS meaning -- time
   of last modification to the content -- instead of time of last
   version control action or time of last commit? Anyone have a
   simple, reliable way to do this now? I am doing this work on
   Windows but the concerns are not OS-specific since file timestamps
   generally have the same meaning in most typical OS's.

original timestamp preservation
    Ben Collins-Sussman <sussman_at_collab.net>
    Date: 2005-06-28 19:52:12 CEST
    "This question keeps coming up, over and over, in both
     IRC and the users@ list: 'When I import a project into
     subversion, why aren't the original timestamps being
     preserved?' A lot of newbies are surprised. Some are
     frustrated and throw insults at the project. And to
     make things worse, the answers they get back are mixed.
     I feel like we're in a state of limbo regarding our
     "official" project answer to this question. What I'd
     really like to do is write a new FAQ that says either
       * Subversion has no plans to support this feature,
         here's why.
       * Subversion plans to support this feature someday,
         here's the filed issue.
     Sometimes users are told, "hey, go try this branch from
     p.marek, it should do what you want".
     But is that branch really supported? Will it ever be
     integrated? My recollection is that at some point we
     were in process of trying to squeeze a real design spec
     for the feature, but because that never quite happened,
     the branch is just sitting there. Other times, we give
     users the opposite message. Some of us (like me) think
     the feature is unnecessary. Most everyone who complains
     about the current behavior is upset because their FTP
     scripts can't sync stuff based on timestamps anymore,
     to which we say: "change your processes, you should
     be using 'svn up' to sync things now." So what I'd really
     like to do is pull ourselves out of limbo on this issue.
     Are we going to file an new-feature issue to develop a
     real design spec? Or are we going to give an official
     explanation as to why we're not doing the feature? We
     need to decide.
     Tardif, Sebastien <STARDIF_at_anacomp.com> !!++
     Date: 2005-06-28 20:54:27 CEST
     "So let me resume my frustration: From the point of view
     of a user, Subversion is just a tool that should be
     transparent as possible. The only common knowledge my
     mommy and I know about computer is that files as a name
     and a modification date. In the perspective of knowing that
     subversion know about the UNIX security flag but doesn't
     know about the original modification date is quite
     perplexing. Other thread asked this important question:
     "While should we care about the commit date of a specific
     file instead of it's modification date?". This should set
     the answer to: "What should be the default behavior?"
     From: Branko <brane_at_xbc.nu>
     Date: 2005-06-28 21:40:08 CEST
     "The catch here is that 99% of the time, the commit time
     _is_ the modification time, as far as the repository is
     concerned. I also suspect that in most cases when people
     import files into the repository, original modification
     times have no meaning. Storing the original modification
     time on import would only make sense if "svn co" and
     "svn up" set file timestamps to the times stored in the
     repository. But this is a bad idea in most cases if those
     files are program sources, because most build systems use
     file modification times to decide whether dependent files
     should be rebuilt. On the other hand, since SVN is a
     version control system, not a source control system,
     there are many valid cases where the opposite is true.
     The trick is to decide which behaviour should be the
     default, and whether it should be controlled on the
     server or client, per-repository, per-working-copy or
     even per-file. I think the only sensible solution would
     be to control it per-file (or per-subtree), but controlling
     such behaviour in a sensible way probable requires
     server-side config and/or inheritable properties, a can of
     worms we've avoided crossing so far...
     Greg Hudson <ghudson_at_MIT.EDU> !!++
     Date: 2005-06-28 22:05:25 CEST
     "I think it would be sensible to control it per-working-copy,
     with a checkout option. It might not be ideal for everyone's
     use cases, but it would be sensible.
     Marcus Rueckert <darix_at_web.de>
     Date: 2005-06-28 21:47:31 CEST
     "in most cases the last modified date and the commit
     date shouldnt differ more than hmm 2h... at least for
     normal development work"
     Peter McNab <mcnab_p_at_melbpc.org.au> !!++
     Date: 2005-06-29 03:14:18 CEST
     "Maybe a compromise would satisfy a number of folk, like
     me. I inherited two large code bases, (over 2000 source
     files and hundreds of binary data files) with no recourse
     to the originating team. The only historic information
     available was contained in the last modified date-time
     stamp for each file. On import the whole historic perspective
     is lost. It would be really, really, helpful if the original
     date-time stamps could be preserved at the point of
     importing them into a their new repositories. There-after,
     the most meaningful time is of course the commit time.

Re: original timestamp preservation
    Molle Bestefich <molle.bestefich_at_gmail.com> !!++
    Date: 2005-07-07 12:41:11 CEST
    "... That problem can be solved at import time, at least
    if you're willing to import each file into it's own revision.
    That way you can set the svn:date for each revision,
    effectively getting a commit time that corresponds to each
    file's last modification time. Here's an example bash script
    (function, really)

Status of meta-data-versioning (mod time)?
   Oliver Betz <list_ob_at_gmx.net> !!++
   Date: 2005-07-07 22:12:32 CEST
   "Hello All, sorry if this has been discussed recently, the
   mailing list archive dies repeatedly with different error
   messages so I couldn't read everything. Is there any chance
   that "meta-data-versioning" (of modification time) will be
   available soon in a release version? Does it work time
   zone independent (UTC)? TIA, Oliver
   Ph. Marek <philipp.marek_at_bmlv.gv.at>
   Date: 2005-07-11 09:18:09 CEST
   "Please see issue 1256
    and the thread...
   Oliver Betz <list_ob_at_gmx.net>
   Date: 2005-07-11 12:47:01 CEST
   "I have been reading all this, but wanted to know whether
    this will be integrated to the _release_ version soon.
    Building a Windows version doesn't seem to be funny.
    In the mean[time] I found a thread ("original timestamp
    preservation") in the developer list
    http://svn.haxx.se/dev/archive-2005-06/ Reading this, it
    doesn't seem that timestamp preservation will be
    implemented soon. Importing legacy files' metadata etc.
    doesn't seem to be considered important by the developers.
    In their world, every project seems to be started under
    version control. Well, that's not the real world.
    Ben Collins-Sussman <sussman_at_collab.net>
    Date: 2005-07-11 15:21:33 CEST
    "Not true at all. Rather, we expect that 90% of the time,
    projects will be 'svn import'ed into subversion. Once
    the project is in subversion's repository, tell me why
    you still care about the original timestamps. I'd like to
    know. The answer I always hear is, "I have a whole bunch
    of scripts that depend on timestamps to perform copy
    synchronizations!"... to which I'm not sympathetic.
   Ph. Marek <philipp.marek_at_bmlv.gv.at> !!++
   Date: 2005-07-11 15:35:32 CEST
   "Well, others just have to do things with files which don't
   involve subversion ... maybe sending and receiving from
   third parties (where timestamps are a simpler [and for
   big files faster] way to check than hashes), maybe there's
   some medium or endpoint involved where it's not possible
   to do a full subversion chain (think mirrors and svk) ...
   Not everyone has complete control over the working data."
   Ryan Schmidt <subversion-2005_at_ryandesign.com>
   Date: 2005-07-11 15:50:29 CEST
   [[ Ben Collins-Sussman: 'tell me why you still care about
   the original timestamps.' ]]
   "How about "I'd like to know, before I imported this into
   Subversion, when the last time was that I edited some file."
   Oliver Betz <list_ob_at_gmx.net> !!++
   Date: 2005-07-11 18:23:28 CEST
   [[ Ben Collins-Sussman: 'we expect that 90% of the time,
   projects will be 'svn import'ed into subversion.']]
   "in which state/age? My "embedded" industrial applications are
   rather long-lived, stuff from 1993 (long before I thought about
   using version control) is still maintained. IMHO the timestamp
   is a rather meaningful property if there is no equivalent
   information in the revision log. Well, with a small script I can
   (and will) add/commit each file at a time and tweak the commit
   time, this way the project history keeps similar information
   as if being under version control from the beginning. But it's
   a rather ugly (and slooow) hack.

   [[ 'Once the project is in subversion's repository, tell me why
   you still care about the original timestamps. I'd like to know.' ]]
   "People gave already many reasons in past threads, for example
   handling files not being source text, files from external sources.
   Another reason: As long as there is any connection to the "pre-svn"
   status of the project, the timestamp is a important indicator or
   helpful to find the connection. For example, there might be more
   than one version (branch) from "pre-svn" ages, those files can be
   identified/compared by their timestamp. After modifying a file the
   first time under version control, the original timestamp is
   usually (!) no more important, since commit time is as good as
   mtime in most (not necessarily all) cases.

   I also agree with others that svn should be able to "touch" the
   affected local files on commit so that the working copy has
   the same timestamp as the commited revision. This would cause
   "make" to compile the files again (as it would happen using
   substitutions), but one had at least identical working copies
   (if using use-commit-times).
   Scott Palmer <scott.palmer_at_2connected.org> !!++
   Date: 2005-07-11 20:03:32 CEST
   "If Subversion is going to throw away metadata that most other
   file operations (most copy, ftp, http file transfers for example)
   preserve, e.g. mod times, then the onus is on it to justify that.
   So far the answer I always hear is, "always use subversion to track
   file versions"... to which I'm not sympathetic. :-)

   I have no desire or ability to force everyone and everything I
   exchange data with to use Subversion exclusively. Mod times would
   work fine for tracking file versions, if tools like Subversion
   didn't break them (and insist they were useless in the first place
   because some other tool might break them as well).

   There are plenty of existing tools and/or scripts out there that
   do their work based on time stamps. Subversion itself argues that
   'make' only works properly if the time stamps are just so. It is
   the reason often quoted for NOT tracking the file mod times... and
   yet it seems the developers ignore the fact that other tools use
   time stamps in similar ways and work best when the mod time is
   accurately tracked.

   Why should everyone change their workflow to accommodate the
   fact that subversion doesn't save meta-data? That "whole bunch
   of scripts" may be difficult or impossible to change. Filesystems
   keep track of mod times for a reason. Why does subversion assume
   that reason goes away completely with a VCS in place? The OS'
   filesystem is still there! You don't assume 'make' is integrated
   with Subversion, why assume everything else must be?

   Karl <kfogel_at_collab.net>
   Date: 2005-07-11 20:08:23 CEST
  "Sometimes we decide the benefit isn't worth the cost."
   Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com> !!++
   Date: 2005-07-12 11:34:36 CEST
   Reasons why I want to have it [accurate per-file timestamps]:
   - Tar files store it. I want to be able to give some stuff to
   someone else in the form of a tar file. If I want to give him/her a
   new version, taken from a freshly checked out WC, then all timestamps
   are different from the old version, even though there are changes
   in a few files only (this could be solved using --use-commit-times,
   maybe, at least to some extend).
   - 'make' uses them. If the right order is preserved, this could
   also be solved using --use-commit-times, but right now I believe
   that the right order is not preserved.
   - These informations are stored and presented by every unix/linux
   filesystem. Not storing them renders this part of the filesystem
   useless. Why did the developers of the filesystems take the effort
   to implement it? Because there is some use to it, whatever it may
   be, perhaps something I never thought of.
   - People, including me, want to know "when was the last change to
   that file?", even if the file was laying around for some time
   (months/years!) before being put under subversion control. This
   problem cannot be solved using --use-commit-times.
   In general, when putting something under a VCS, I want to lose
   *as little information as possible*.

Importing and adding files with actual time stamp?
   From: Marko K--ning <mk362_at_mch.osram.de> !!++
   Date: 2005-07-26 13:43:56 CEST
   "Hi, is it possible to force subversion to use a files time
   stamp during import and add? I would like to preserve the date
   and time of the file somehow. This had been a problem in CVS,
   but perhaps it can be done in subversion? If so, is there also
   a way to check out a file recovering its original time stamp?

Import and Commit and file modification times
    Svante Seleborg <svante_at_axantum.com> !!++
    Date: 2005-08-12 19:41:51 CEST
    "I'm in the process of incorporating a significant set of
    code to a Subversion repository...But... When importing and
    committing, it appears that Subversion will use the time of
    the import and the time of the commit as the "last-commit"
    time in the repository. Using the time of the import and the
    time of the commit is not at all what I'd expect - and apart
    from the loss of meta information, it breaks my build tools
    which actually depend on those file modification times.
    This occurs both during an initial import (I guess I could
    survive that), but also when comitting, as the internal
    order of modification of the comitted files are not retained
    in the repository. I must be missing something! Please let
    me know the obvious solution. I have read the FAQ, spent an
    hour searching the SVN book, but all to no avail."
    Ph. Marek <philipp.marek_at_bmlv.gv.at>
    Date: 2005-08-16 07:47:40 CEST
    [describes patches being worked on (?)]

Re: Import and Commit and file modification times
    Ph. Marek <philipp.marek_at_bmlv.gv.at>
    Date: 2005-08-17 09:19:57 CEST
    [As far as I'm concerned it's a major "bug" in the design of
    SVN. I am once again missing something obvious such that
    there are major use-cases where such a merge would break
    something? I can't see the problem with supporting proper
    date-time stamps on files. Are there any plans to merge
    this with the mainline? Svante
    http://marc.theaimsgroup.com/?l=subversion-dev&m=112418966912502&w=2 ]
    "I've already discussed that several times ... the core
    developers seem not to be interested. But maybe if enough
    people complain ... Regards, Phil
    Svante Seleborg <svante_at_axantum.com> !!++
    Date: 2005-08-17 10:19:48 CEST
    "Most projects do not begin with a clean slate and an installation
    of Subversion. Most of us have code that we want to start with,
    and import. Part of that code consists of various meta information,
    such as the file name and last time of modification (NOT last
    time of commit! - That is a different story, and is about
    migration from one repository to another). Unfortunately these
    two issues adds up to Subversion currently not being such a
    totally compelling replacement for CVS as I'd like, and for
    many with me apparently. On a very fundamental basis, I think
    it's important to think about what a repository and source code
    control system does, and should do. In my mind - the operation
    sequence: Import - Checkout/Export should be a no-operation as
    far as the sources involved are concerned - i.e. they should
    not be modified!!!
    Svante Seleborg <svante_at_axantum.com>
    Date: 2005-08-18 07:00:48 CEST
    [ 2) We're already working on this, it'll probably be in 1.3.]
    Assuming "this" is the timestamp issue, that's great news!
    It's obviously kind of late to affect the outcome, but it
    would be really nice if it made it into 1.3. According to the
    project status page it's medium priority (3) and only
    "considered" for inclusion into 1.3. I'll keep my fingers
    crossed, hope for the best, and wait for that for the final
    migration to SVN. Svante.
    Svante Seleborg <svante_at_axantum.com>
    Date: 2005-08-18 09:04:28 CEST
    "Still hoping for "proper" timestamp handling in 1.3. I cannot
    use SVN before then. Anyone who can respond to the real issue?
    Will timestamp metadata preservation make to the 1.3 release?
    Ben Collins-Sussman <sussman_at_collab.net>
    Date: 2005-08-18 23:20:12 CEST
    "I don't think anyone's working on it. The reason the feature
    doesn't exist is because a formal design has never been proposed
    or discussed. Ph. Marek was kind enough to code up something
    "which works", but that branch has never been merged to
    trunk. It won't be merged until someone picks up the lead on
    this feature and leads the design discussion.
    Rob Anderson <rob.anderson_at_juicegames.com> !!++
    Date: 2005-08-19 10:46:09 CEST
    "But issue # 1256
    is marked as 1.3-consider and status 'started', assigned to kfogel.
    Doesn't this mean that someone is working on it? Or has it been
    marked as started since 2003? ;( Rob.
    Svante Seleborg <svante_at_axantum.com>
    Date: 2005-08-19 11:51:55 CEST
    "(snip) I saw that, I hope it means kfogel is indeed working
    on it...

    As for the design discussion - what is required? It seems
    fairly straightforward, especially as there is a working
    sample of code.

    I'll be willing to lead that discussion, but out of necessity
    it'll have to be fairly high level to start with, not having
    studied the code or design of SVN at all.

    Perhaps I'm naive, but something like this might serve as
    the start of this design discussion:

    - Design goal: Import followed by export/checkout from the
      same client system should be a no-operation affecting
      nothing of file contents bit-for-bit or the meta data
      "file name" and "file timestamps".

    - When checking out on a different file system than imported
      from, the best possible approximation should be done.
      Filenames are treated as today. Timestamps are rounded to
      the nearest value in the target file system resolution.
      If exactly half, always round up to a more recent time
      (err on the side of a non-existing update rather than
      the other way).

    - Add two more meta-data (properities I suppose) to the
      repository: time-last-modified and time-created.

    - Default behavior at import is use what is available on
      the local file system for time-last-modified and time-created.
      If only one timestamp is available use it only for
      time-last-modified , and leave time-created undefined.

    - Default behavior at export is use available properties.
      If time-created is available use it for that. If
      time-last-modified is availabled use it for that. If the
      local file system only supports one time stamp, use
      time-last-modified and ignore time-created even if
      available. If neither time-last-modified or time-created
      is available, use current behavior.

    - Default behavior at checkout is current behavior
      (for compatibility). Add a client-side switch analogous
      to the use-commit-times, use-file-times perhaps. When
      set, both export and checkout use the defined behavior.

    - Store times with resolution and time zone information
      (UTC I presume) as is now done for commit times.

    - If time-last-modified or time-created is in the future
      from the view of the server at import/export/checkout
      do nothing, just accept it (possibly inform). (If the
      user for whatever reason wants this - that's her choice.
      The repository should not police such a situation).

    I'm sure there are file system quirks, and possible SVN
    design issues, that makes some things need to be handled
    differently than above, please comment on this.
    Philip Martin <philip_at_codematters.co.uk>
    Date: 2005-08-19 17:28:18 CEST
    [questions, comments]
    Svante Seleborg <svante_at_axantum.com>
    Date: 2005-08-19 18:04:09 CEST
    "[Directories also have timestamps, on Unix at least, should
    these be stored as well?] My vote is "yes". They do have
    filestamps in Windows file systems too.
    Philip Martin <philip_at_codematters.co.uk>
    Date: 2005-08-19 18:38:25 CEST
    [questions, comments]
   Philip Martin <philip_at_codematters.co.uk>
   Date: 2005-08-19 20:28:44 CEST
   "The value of the timestamp property doesn't matter as far as the
   next commit is concerned, only the presence of the property matters.
   If you resolve conflicts to the latest time value that will probably
   cause the properties to show up as modified in the status output, I
   don't think that useful. I suspect that merge should add/delete the
   property but should never change its value.
   Svante Seleborg <svante_at_axantum.com>
   Date: 2005-08-19 21:59:25 CEST
   "if we regard the timestamp property on equal footing with
   other metadata such as the file name, I'd say that a change
   in the time value should indeed show as modified in the status
   output. It's kind of an artificial case, but "touch" is such
   an example." My proposed design would indeed detect changes
   betwen the timestamp and the corresponding property, and would
   indeed allow a commit after a "touch". It's the whole point
   - file modification times are an integral part of what the
   repository should store and version. A hypothetical project
   where the only changes was a "touch" would generate a new
   version for each commit with a different timestamp.
   Joshua Varner <jlvarner_at_gmail.com>
   Date: 2005-08-19 23:16:58 CEST
   [questions, comments]
   Svante Seleborg <svante_at_axantum.com>
   Date: 2005-08-19 23:28:59 CEST
   "We're versioning files. They have, as a very tightly
   coupled item, one or several pieces of meta-data attached.
   In current file systems this is pretty much limited to
   timestamps, but no less important. I will maintain that
   import/commit followed by export/checkout should preserve
   the identity relation between the two sets as far as possible,
   including file names and file timestamps. Timestamps are
   an important piece of the history of a project. This
   currently gets irrevocable lost once imported into SVN.
   Yes, but *you* might be interested when that picture was taken
   - not only when it was placed into the new and shiny album
   you bought a few years later. I'd be mighty annoyed if the
   time the picture was taken was available before putting it
   into the album, and then changed to reflect the time when
   I put it into the albubm, and even worse not being able to
   get that time back when I decide to take it out of the album
   Svante Seleborg <svante_at_axantum.com>
   Date: 2005-08-19 23:34:42 CEST
   "Why would files get different timestamps without any
   modifications in this scenario? On the contrary, I'd say that
   the current default behavior of Subversion would cause such
   problems, but the proposed design would solve them. As long as we
   stay away from unusual scenarios with manual changes to just
   the file system or repository timestamps, the true preservation
   of timetamps in the repository will ensure that such things such
   as timestamp based sync actually does work as intended.
   Joshua Varner <jlvarner_at_gmail.com> !!++
   Date: 2005-08-19 23:50:39 CEST
   "You asked for a case where keeping the latest property value
   would be bad. There were two copies of the file with identical
   timestamps, then the one on the trunk is changed causing its
   timestamp to update. This change is then merged into the branch
   causing that file to change and its timestamp to update.
   However, when merged back into the trunk the two files are
   identical except for the timestamps. In the current case
   nothing is done since the timestamp is ignored, but if it is
   being preserved then there is a "conflict" since the two
   values differ. In the use case I describe you would want the
   earlier (not latest) version of the time stamp b/c you are
   concerned with changes to the content. Yes the obvious thing
   is to keep the older one, but this is not specified in your
   design, that's the only issue. If the consensus is to keep
   the older one, then that's fine it just needs to be explicit
   in the design. It's not an argument for or against the feature,
   just a design detail that should be resolved prior to
   Michael Sinz <Michael.Sinz_at_sinz.org> !!++
   Date: 2005-08-20 00:33:08 CEST
   "Ahh, but you have brought up that is what SVN does today,
   which is not true. The timestamp is not the only indicator/
   exclusive indicator of file changes. If you are proposing a
   change to this then I would think that there are many, many
   other issues that will come up, not the least of which will
   be the broken build process (for anyone using timestamps
   such as Make uses) [...] Now, that is not to say that there
   are no cases where I would like the file timestamps tracked.
   Just like I would like other meta-data tracked. But if you
   are looking to help the build process, this is the wrong
   way to do it. BTW - I *do* want the import operation to
   track the timestamps of the files as this is the first
   commit. In fact, I may also want that for the general
   commits, just as other meta-data.
   Ph. Marek <philipp.marek_at_bmlv.gv.at>
   Date: 2005-08-22 13:49:13 CEST
   "Just to throw my 0.02 into the pool - my thoughts were
   approximately these (was some time ago - may 16th, 2003
   http://svn.haxx.se/dev/archive-2003-05/1360.shtml :-)
   - As all meta-data it should be versioned. (Doesn't need
     much space, after all)
   - Should be tuneable per-file (property is needed on file
     or directory to be set)
   - To preserve performance as much as possible the
     wc-property is set to the *real* value only on commit.
     So a file/directory has to be committed to have its
     property set, and to be committed it has to have
     text-changes (is that still so?).
   - In the first patches I had some code which tries to
     handle conflicts in the text-time property; it worked by
     taking the newer of the two, or taking the file's real
     modification time (the time of the merge). As we didn't
     use branches then I think I dropped it in the newer versions.
   - On update/checkout/export the text-time is simply taken
     and used.
   - There's no saving of the creation-time; the mtime is
     all I ever needed, and talking users to tell me the
     creation time was always cumbersome, and mostly void,
     as eg .zip doesn't carry the ctime, only mtime.
   Svante Seleborg <svante_at_axantum.com>
   Date: 2005-08-22 19:30:48 CEST
   "I'm just now reconsidering if I should forget the advanced
   stuff, and propose a simple option to Import instead - it
   would actually fix 95% of my grievance with the current system...
   The idea would be that on initial import, optionally set the
   time of "commit" to the "mtime" as you call it above of the
   imported file. Along with the use-commit-times option, this
   would actually work well enough for me...
   From: <kfogel_at_collab.net>
   Date: 2005-08-22 22:00:43 CEST
   "[[Svante Seleborg <svante_at_axantum.com> writes: But issue # 1256
   (http://subversion.tigris.org/issues/show_bug.cgi?id=1256) is
   marked as 1.3-consider and status 'started', assigned to kfogel.
   Doesn't this mean that someone is working on it? Or has it
   been marked as started since 2003? ;( I saw that, I hope it
   means kfogel is indeed working on it...]]
   Apologies -- I'm not working on it, haven't been for a long time.
   I've fixed the issue. -Karl
   Rob Anderson <rob.anderson_at_juicegames.com> !!++
   Date: 2005-08-23 00:39:59 CEST
   [[ Apologies -- I'm not working on it, haven't been for a long
   time. I've fixed the issue. -Karl]] Oh ok - that's a shame.
   There has been some interesting discussion here on this thread.
   Although I haven't contributed anything to that yet, I have
   to own up to being very interested in getting this feature into
   svn. However I don't know yet how that's going to happen, so I
   have to ask 1) when does a discussion turn into a design, 2)
   when does a design become implemented, and by whom, and
   3) when does that implementation find its way into a release of
   subversion? I realise that there must be many other features
   which may take priority, and so my questions apply equally to
   any new feature being considered. Thanks, Rob.
   Ben Collins-Sussman <sussman_at_collab.net>
   Date: 2005-08-23 04:29:56 CEST
   [explains development process]

Re: Importing and adding files with actual time stamp?
    Marko Kaening <mk362_at_mch.osram.de> !!++
    Date: 2005-09-08 14:06:10 CEST
    [is it possible to force subversion to use a files time
    stamp during import and add? I would like to preserve the
    date and time of the file somehow.] "Is this patch being
    planned to become incorporated into subversion by default
    at some time?"
   Marko Kaening <mk362_at_mch.osram.de> !!++
   Date: 2005-09-08 15:03:02 CEST
   "post describes exactly also my dilemma. SVN is quite nice,
   but I would be much happier if timestamps would be kept by
   default! I hope that this problem really gets to the
   developers. Would be great to have that feature! Marko
   (Just to be fair: CVS doesn't keep the timestamps either.
   But: Though that's no excuse not to fix this design flaw.)"

Couple suggestions issues
    Gregory Raiz <graiz_at_raizlabs.com> !!++
    Date: 2005-11-01 18:12:53 CET
    "I've experienced a couple problems recently. Any insight or
    help would be appreciated... (2) When checking out files
    they should be stamped with the correct "Creation Date" and
    "Modified Date" this way users can sort the files by the
    true creation date not the date that SVN created the file.
    Is there a way to do this?"

FW: date time stamp
  Moss, Patricia <pmoss_at_fcg.com> !!++
  Date: 2005-11-17 15:57:30 CET
  "I noticed that the date/time stamp on the new repository is
  today's date rather than the original date of the loaded dump.
  How can I maintain my original dates?"
  Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
  Date: 2005-11-21 09:52:26 CET
  "Hi, There seems to be a general lack of wanting to maintain
  last modified date times within subversion. See
  for another example. Graeme.

Way to update timestamp to committed timestamp?
    x nooby <xnooby_at_yahoo.com> !!++
    Date: 2005-11-21 19:41:07 CET
    "When someone checks in a file, their timestamp has the
    time of the last edit. When another user gets the
    update, their timestamp has the time of when the last
    edit was committed."
    x nooby <xnooby_at_yahoo.com>
    Date: 2005-11-21 20:09:37 CET
   "I recreated the 'bug', I will ask if it really is one.
    I'm guessing it is a design oversight, or maybe they
    just really don't want it to update the timestamp of
    the guy checking in the file."

RE: Should commited files have the timestamp set to commit time?
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2005-11-22 11:02:13 CET
   "Flipping the logic, I would argue that the last modified
   time should be preserved through the system and not having tools
   modify the last modified timestamp when they are in fact NOT
   modifying the file. See
   I would argue for this also being another bug / deficiency.

[DESIGN] mtime versioning - was: Getting Bug 1256 fixed
   Ph. Marek <philipp.marek_at_bmlv.gv.at> !!++
   Date: 2005-11-23 07:11:45 CET
   "So, to get at least the brainstorming startet, I'll try to
   recreate my thoughts from 2003. What is wanted? - To save the
   (modification-) timestamp for each committed file, and to
   restore them. - Must be specifiable per-file, so that
   single documents within a source tree can use that feature,
   but all others not. - Must not be manually specified for each
   added/imported file. For added it's too much work (or
   a separate script would be needed), and on import it's
   already to late (imported version has no saved timestamps).
   Julian Foad <julianfoad_at_btopenworld.com>
   Date: 2005-11-27 18:41:45 CET
   "So far, so good. Next, develop the requirements section into
   a more detailed design specification that will satisfy those
   requirements (and all the unstated requirements). Write this
   by saying exactly what the software will do, functionally,
   from a user's point of view, with enough precision that the
   reader can work out what would happen in a complicated scenario.
   For example, the reader should be able to determine what
   mtime would be used on FILE after a sequence...
   Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk> !!++
   Date: 2005-11-27 19:23:00 CET
   "It might be useful to include a brief note on why this
   requirement exists in the first place: what need or use case
   isn't being fulfilled by the current functionality?
   Regards, Malcolm
   From: Ryan Schmidt <subversion-2005_at_ryandesign.com> !!++
   Date: 2005-11-27 21:03:15 CET
   "People on this list are constantly going on about how a version
   control system's job is to accept and archive data thrown at it,
   not to change it. This is presented as an argument against many
   user suggestions -- for example, the ability to have a post-commit
   hook do automated syntax formatting on committed source code files.
   The rationale is that the system should not store a modified
   version of what the user commits; it should store exactly what
   the user commits. The same argument should be applied to
   metadata such as the modification date.

   Suppose we have a programmer Joe who can't write any decent
   code before 10 AM when he has his second cup of coffee. Suppose
   he writes some code before 10, some other code after 10, and
   commits everything together at 11. The commit time is 11, and
   when checked out (with use-commit-times on) the modification
   time of the files is also 11. Suppose we are looking at the
   code now and wondering if it is correct. If we could see the
   time at which the files were actually modified, we would be
   better-able to decide which files might be suspect.

   A less-contrived example would be importing an old project
   into a new repository. All files in the project will allegedly
   be modified at the commit time, when in fact the project may
   have been last modified years. The act of importing the project
   in effect deletes the history of the project, and someone who
   later looks at the project will think it's newer than it is.
   Jim Blandy <jimb_at_red-bean.com> !!++
   Date: 2005-11-28 09:42:31 CET
   "Wouldn't it make sense to separate the issue of whether we
   record the file's modification time when it goes into the
   repository from whether we restore it on the way out? I'd
   expect that we would always want to record the modtime in
   the repository -- why throw away information?
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2005-11-28 10:36:59 CET
   "Storage: I would want the modification time stored for every
   revision. Would this property be stored within the Berkley DB?
   If so then wouldn't this be compressed like the rest of the
   database? - on my project the files when exported are approx
   500Mb and the repository size on the initial import was 139Mb,
   thus it must have been compressed. If space is an issue then
   adding a configuration option to only store the latest
   modification time would solve this. As a general rule it is
   always worth storing the information by default and then letting
   the user specify that they do not want it stored.
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2005-11-28 15:47:22 CET
   "I would expect the file datetime to be always preserved as it
    isinformation about the file at the time of checkin. What is
    being proposed here is to extend the functionality to allow
    for the saving of the modification time when a file is commited
    to then give the user three options of what to set the file
    datetime to: 1) The current time, 2) The time of the repository
    checkin, 3) The original File datetime.
    Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
    Date: 2005-11-28 16:23:32 CET
    "My expectations of the logical working of this feature are:
    Import and checkin:
    Global: - Option to store the modified datetime for all files.
    On stores datetimes. Default: on (See requirements 3)
    Per file: - The ability to set a flag to say to store the
    modification datetime. Default: Not set
    Change Checking: - The modification datetime will not be used
    to determine is a file has changed. This will be done using a
    binary compare (as is currently the case)
    Storage: - The modified timestamp for the file will be stored
    for every revision of a file. i.e. it will be stored whenever
    a file delta is stored.
    Export and checkout:
    Configuration: - 4 options available to the client for the setting
    of the modification datetime:
      1) Use the current datetime
      2) Use the checkin datetime
      3) Use the original file datetime. If this was not stored in the
         repository then the current time should be used (this can
         then be used by the user to know that there was no
         modification datetime available)
      4) Use the original datetime for all files that have the per
         file storage flag set. To allow for the people who want
         the docs with their original modification datetime but
         the source with the current datetime.

    Summary: I believe that this covers all of the various use cases
    for this feature which are:
    1) Using it on specific non source files, but keeping compatibility
       with make for source files.
    2) Using it for every file for compatibility with company
       procedures that use the modified datetime to specify a file.
    3) Not using it at all.


    1) Maintain compatibility with the existing system.
    2) Do not change the default behaviour of the system as there
       are a lot of people out there that have expectations of the system.
    3) Enable the novice to set up the system and to then have this
       option available in the future. It would be highly frustrating
       to have worked on a system and then want to get the modified
       datetimes only to find out that you did not set an option that
       you didn't know that you had to. Advanced users that do not
       want this feature can turn it off to save storage space and
       processing time.
    4) Allow the client to choose how they want to get their files out.

    I hope that this is clear, I feel that this is an issue where
    subversion should simply provide the functionality to satisfy
    these use cases and would thus allow for people who want to work
    in whatever way that they want and for their own reasons. I
    personally see the benefits of working with the current time for
    compatibility with make, but at the same time I prefer to work
    with the original modification datetimes and then use
    'make -B' whenever I do an update. It may take a little longer
    but it gives the same safe end result. This modification will
    enable everyone to work the way that they are happiest.
    Thanks, Graeme
    Julian Foad <julianfoad_at_btopenworld.com>
    Date: 2005-11-28 17:05:03 CET
    "[[ 'Per file: The ability to set a flag to say to store the
    modification datetime.']] And: if the flag is set, then the
    mtime is stored. If the flag is not set, then the mtime is not
    set, and presumably any mtime that was previously stored for
    the file is deleted. (I say this in the context of the time
    being stored in an ordinary property, as the property will
    persist from one revision to the next unless the code explicitly
    deletes it.)
    Please can you clarify how (3) and (4) differ. How does "if
    this was stored" differ from "if the storage flag is set"? What
    does (4) do if the flag is not set? This whole message was
    a nice presentation of your requirements, and quite reasonable
    ones too. Perhaps you could re-post it with the above
    clarications included, rather than just answer them in-line,
    so that we have a copy of your proposal to refer to.

BUG? Date Modified on Import
   Andrew Morgan <opticyclic_at_gmail.com> !!++
   Date: 2005-11-30 13:28:44 CET
   "When I imported files from a directory that was last
   modified 05 February 1999, 12:33:10 I expected that date
   to be preserved. However, when I look at the files with the
   repo-browser, the modified date is now the date I checked
   the files in (and obviously when I check the files out,
   the modified date is the check out date). Is there no way
   (apart from adding a screen shot of Windows Explorer
   to the repository) of preserving the modified date of the
   original files? Regards /Andrew

Re: BUG? Date Modified on Import
   Stefan Kueng <tortoisesvn_at_gmail.com>
   Date: 2005-12-01 20:14:39 CET
   [[ 'Is there no way (apart from adding a screen shot of Windows
   Explorer to the repository) of preserving the modified date of
   the original files?' ]]
   "You can make Subversion use the commit times, but that's all.
   See the following section in the Subversion book:
   Have a look at "use-commit-times". Stefan.

RE: FW: date time stamp
   Moss, Patricia <pmoss_at_fcg.com> !!++
   Date: 2005-12-02 14:56:35 CET
   [[ 'There seems to be a general lack of wanting to maintain last
   modified date times within subversion.' ]]
   "I am reading through the threads that you sent and they seem
   to be referencing the import/export and add/commit features.
   The patches that are in these threads seem to be for these
   features as well. Will applying these patches fix my dump/load
   problem? [There seems to be a general lack of wanting to
   maintain last modified date times within subversion.]

   Scott Pritchett <scott.pritchett_at_amtrak.co.uk> !!++
   Date: 2005-12-12 18:47:47 CET
   "I need to retain my date/times on my files. I updated a file.
   I then decided to revert the changes, the date/time stamp,
   however, is not reverted. Scott."
   Sven Brueggemann <SBrueggemann_at_gmx.net> !!++
   Date: 2005-12-12 19:47:01 CET
   "This is a subversion issue. Subversion does not store
   the file's mtimes, so it can't revert it. There was a big
   discussion recently on the subversion lists on how to
   implement preserving timestamps so I think SVN will be
   able to do so some time, but not in the very near future.

[13] ======== Postings from 2006 ========

time stamp
   Askar, Serap (EZTV/3) <serap.askar_at_volkswagen.de> !!++
   Date: 2006-01-02 16:17:00 CET
   "I'm using subversion (version 1.2.3) and have a question
   concerning the timestamps. I would like to add an older
   directory or file to an existing repository, but I need to
   keep the origin timestamp for this file, neither the "last
   commit time" nor the "current time"... Is it possible to keep
   the origin date of existing files while using the add
   command in subversion? It would be nice, if someone could
   give a short answer to this question. Serap Askar, Volkswagen AG
   Ryan Schmidt <subversion-2006Q1_at_ryandesign.com> !!++
   Date: 2006-01-02 20:52:30 CET
   "Unfortunately Subversion doesn't store modification times
   in its repository. It only stores the time of the commit."

Ability to preserve last modification time of files under version control
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com> !!++
   Date: 2006-01-12 16:16:52 CET
   "Any chance of trying to get this issue into 1.4? This is a popular
   issue that has been through the requirements phase and
   should now be in the design/implementation stage. Also there is a
   working patch that can be used to guide the design and
   implementation. It has now coming up to 3 years that this has been
   an active issue, it would be nice to finally get this sorted out."
   Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk> !!++
   Date: 2006-01-12 18:03:42 CET
   "I think this is far too late for 1.4, given that we don't even
    have a concrete design yet. As far as I'm aware, Julian's message
    (http://svn.haxx.se/dev/archive-2005-11/1383.shtml) from the last
    time this was raised still represents the current state of the
    design. Developing a document that answers the questions posed
    in that message would be a very good starting-point for anyone
    who wants to see this feature implemented."
    Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
    Date: 2006-01-12 18:10:00 CET
    "This was the last time that it was raised:

File timestamps
   Paul Koning <pkoning_at_equallogic.com> !!++
   Date: 2006-01-09 01:34:27 CET
   "I just had a battle with a build procedure -- quite possibly
   one that isn't really done right -- that made me rethink the
   earlier discussion about file timestamps. The situation
   (I think) is that there's a directory that contains some
   generated files as well as the files from which they are
   created. Something like configure.in and configure, for
   example. And in our regular build procedure we depend on
   the generated files; we don't go all the way back to the
   beginning. Part of the reason may be that we don't have all
   those tools installed. With CVS, I believe the original
   file timestamps carry over. So the generated files appear
   newer, in my working directory, than their sources. That
   means that dependencies work correctly. With Subversion,
   by default, the timestamps are checkout time. More precisely,
   the time when a particular file was created by the checkout.
   Depending on the order in which files come across from the
   server, that may mean the generated file appears a few
   seconds older than its source file. And that is what
   happened to us. So the build procedure failed, because it
   tried to regenerate the generated file and things weren't
   set up for that....How about this solution: Checkout
   (and switch) use the commit time, or the original
   modification time. But update uses the update time. If
   that were an option I think it would be the best of
   both worlds. It might seem messy, but it seems to have
   better properties for the user than any of the existing

Re: Effects of importing over 18000 items into repository as one
commit transaction
   Molle Bestefich <molle.bestefich_at_gmail.com> !!++
   Date: 2006-01-12 00:06:54 CET
   [[ 'Pavel Repin wrote: Should we have imported that tree as a
   set of smaller checkins?' ]]
   "If you ever feel that you want to do that, I posted a script to
   this list once that will submit each file in its own revision.
   What's the use, you ask? Well, it will preserve your current
   last-modified-timestamp on files, which means that each file's
   date in your repository will reflect the actual times that the
   files were last modified, instead of the time when you did an
   initial import into Subversion. Ho-hum.

Preserve commit times (issue #1256)
   Matthew Sanderson <matthew_at_formtrap.com> !!++
   Date: 2006-03-08 06:05:28 CET
   "I would like to be able to commit/import a file F1 to the
   repository, then check that file out or update it, yielding a
   file F2 in another working copy, and have F2's time of last
   modification be the same as F1. Ie, the checkin+checkout
   procedure should preserve the file's mtime. The
   'use-commit-times' config option doesn't do what I want.
   This is issue #1256, which has been around since SVN 1.0 or
   earlier. There's a stale, incomplete patch that attempts to
   add this functionality:
   [...] Is this the only way to do this? It's a little ugly. Are
   there any future plans to support this in Subversion itself?
   The reason I want this is because I have source and generated
   files in a repo, and a bogus Make rule which claims to be able
   to generate the generated files from the source files, but which
   actually exits with an error instead of doing the generation,
   because the generation can only be done manually by a human on a
   different operating system. So this is a check for a human
   omission. I imagine there exist less corner-ish cases in which
   this functionality would be useful, too. Cheers, --matt
   Ryan Schmidt <subversion-2006Q1_at_ryandesign.com>
   Date: 2006-03-08 10:49:37 CET
   "[[ 'I.e., the checkin+checkout procedure should preserve the
   file's mtime. The 'use-commit-times' config option doesn't do
   what I want.' ]] "The use-commit-times option sets the modification
   time of files, on checkout or update, to the time they were
   committed. If that's not enough for you -- if you need to store
   the actual modification time of the file, separately for each
   file within a single commit, then the meta-data-versioning
   branch may be for you:

RE: Preserve commit times (issue #1256)
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2006-03-08 11:03:23 CET
   "Bug updated with link to design discussion:
   I see that this is slipping again!"

   Andre Steenveld <a.steenveld_at_id.umcn.nl> !!++
   Date: 2006-03-20 16:51:48 CET
   "Hi, I've started to use svn recently but bumped into some
   problems related to date/time stamps. What I want might be
   impossible. Anyway I can't find out in the documentation, FAQ
   or this lists archive records. Per default svn changes date/time
   stamps on import, checkout and update in a way that, strictly
   spoken, is not needed. I'm using the time stamp for some other
   purposes as well and I would like to preserve the original
   time stamp, if possible. (For instance, on some files from
   external sources, there is a version number but it is seldom
   used. The source will refer to 'file xxx with date/time stamp yyy')
   I don't think that svn has a need to change the timestamps. The
   combination of revision number with date/time stamp is unique
   and ordered, also in the case if the timestamp of revision
   x+1 is before the timestamp of revison x. (First sort on revision
   numer then sort on date/time stamp, all calculations are just a
   bit more complicated compared sorting on 'only' the timestamp).

   [...] Is there a way to configure svn in such a way that it
   keeps the original date/time stamps? If so, how? If not, is
   this a design limitation of svn? Kind regards, Andre Steenveld

Timestamp help FPGA HDL
   Rolando <rrubalcava_at_micron.com> !!++
   Date: 2006-07-06 18:22:07 CEST
   "I am looking for SVN to allow a user to upload a repository
   to an SVN server with original timestamp info and pull that
   orig timestamp info back... when you pull down a working copy
   and then move the program's /DB directory preserving the
   original timestamp information into the path of the SVN sources,
   SVN has affixed the commit time timestamp and not the original
   timestamp.... I then fire up the program and hit the compile
   button. The program compares the timestamp of the SVN sources
   to the files in the DB and sees the sources as being "Newer"
   due to the commit timestamp so it recompiles...
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-07-06 19:14:04 CEST
   "You may want the client-side option use-commit-times. Look
   in your client's config file.
   Ryan Schmidt <subversion-2006c_at_ryandesign.com> !!++
   Date: 2006-07-06 19:14:04 CEST
   "If you would like to keep track in the repository of the
   time when the file was modified instead of the time it was
   committed, then Subversion cannot do that out of the box.
   There is a branch of Subversion available, called the
   text-time branch, that you can build yourself which
   includes this feature. See:

Keeping last-modified dates
   Andrew Webb <andrew.microi_at_gmail.com> !!++
   Date: 2006-08-28 09:32:47 CEST
   "I'd like to add my voice to those calling for SVN to keep
   files' last-modified date/times. I see you have this as being
   considered for 1.5. I'm trying to persuade my day job to move
   from VSS to another system. Subversion is the first choice. I
   installed SVN and Tortoise over the weekend, and have been busy
   playing and enjoying. I'd say that the only basic feature that's
   missing (compared to our current VSS use) is keeping files'
   last-modified times. These are important to us. Thanks for SVN
   and thanks for listening. Andrew Webb"
   [why? "tell us your use-case please!"]
   Andrew Webb <andrew.microi_at_gmail.com>
   Date: 2006-08-28 20:59:37 CEST
   "Apart from the fact that it's of general interest to me when
   a code file was last modified (something that seems to get
   lost when you import the files into an SVN repository), my
   main use-case is that of copying only those files that have
   changed to a virtual machine, where I build installers...
   Another use-case is receiving data files from, and sending data
   files to, people who are external to the developer team
   (e.g. marketing folks, or even clients) who don't use
   source code control. Although documents should have in-document
   revision histories, sometimes this doesn't happen with the
   desired accuracy. In this case last-modified dates on the files
   can prove invaluable in checking which is the most up-to-date
   copy of a document. This is why we're careful to always
   Zip-compress files, even a single file that would be considered
   as a safe email attachment: Zips maintain the last-modified dates.
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-28 22:18:46 CEST
   [response:] "As for your desire for modification dates for this
   reason, I'm not sure what to suggest. Once you get going with
   the project, any time you check in, the revision will have the
   date and time at which you checked in. Which is just about as
   good as a modification date and time, so long as you don't wait
   to long between modification and checkin. And you can use the
   "use-commit-times" option so that, when you check out or update,
   you don't get the current date and time but the commit time.
   Maybe that's good enough for what you need...."
   Andrew Webb <andrew.microi_at_gmail.com>
   Date: 2006-08-29 08:20:58 CEST
   "Speaking generally, I feel that any system that stores or
   transmits or otherwise deals with files should honour the
   contract of last-modified times. I.e. the time on a file should
   be the last time its contents were changed. The fact that I can
   import files into SVN and then export them and lose that
   information seems wrong and unnecessary. To be honest it's
   created a bad first impression, and I will have to check with
   Gavin Lambert <gavinl_at_compacsort.com>
   Date: 2006-08-29 09:16:00 CEST
   "... Modification dates are fairly useless as a measure of
   anything interesting. It doesn't take a lot to make a file
   change its date..."
   Andreas Mahel <andreas.mahel_at_ch.ibm.com> !!++
   Date: 2006-08-29 10:47:44 CEST
   [[ When you 'svn export', you are creating new files, which,
   naturally enough, have both creation and modification dates
   set to the time they're created. Where's the problem? ]]
   "I wouldn't really call it "naturally", it's just one possible
   way to view things. It's the very low level, traditional Unix
   way of looking at files - each inode is a separate entity and
   the system doesn't "care" how it's been created. Also the "cp"
   command on my Linux box behaves this way (the copied file will
   have a brand new last modification time). However, the way
   many users perceive a file is different. If I create a copy of
   a file, I would expect that not only the content itself is
   duplicated but also some of the meta information, like the
   last time when this content has been modified. This is the way
   it is handled by Microsoft operating systems (and even though
   I'm *not* a big MS lover, this one I find quite nice). This
   behaviour is also the default for the KDE file manager Konqueror,
   and even the "cp" command has its --preserve switch. And
   since subversion can be seen as a versioned file system tree,
   and checkout and commit as copy operations in the two
   directions, I'd strongly vote for the possibility of keeping
   the modification date.
   Andrew Webb <andrew.microi_at_gmail.com> !!++
   Date: 2006-08-29 13:19:08 CEST
   "This [SVN EXPORT generates new "now" timestamps] is not natural
   for me. Thanks to Andreas for pointing out that it's a Microsoft
   thing. I'm a Windows developer and don't know what other
   OSes do. As a Windows user, I know exactly which operations
   will trash a file's last-mod date, so I navigate around them.
   It's as natural as breathing. Sending a file (even one) as
   an attachment to an email or uploading to an FTP server?
   Whack it in a Zip file. I think that SVN would feel more natural
   to us Windows people if it had the option to honour the Windows
   file system's semantic contract for last-modified dates."
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-29 14:07:51 CEST
   "Well, actually, before it ['copy' preserves the file timestamp]
   was ever a Microsoft thing, it was an Apple thing. Macs have
   done this since 1984."
   Marko Kaening <mk362_at_mch.osram.de> !!++
   Date: 2006-08-29 18:35:05 CEST
   "I brought this question up too, at least a year ago, or so.
   Answers were quite the same: make etc... But what gives me
   hope for the inclusion of an option to PRESERVE the
   actual time of a checked-in file is that there is more than
   only one or two requests for such a feature. I personally use
   SVN not only for source code (mostly under Windows), but also
   for ALMOST ALL my other files (DATs, DOCs, XLSs, PPTs and many
   more), because I work on more than only one computer, but
   want to have my up-to-date files on all of them with complete
   history... In this situation I do miss this feature [timestamp
   preservation] quite often. It's really sad to get always the
   timestamp for the check-in time, instead of the actual
   timestamp on all these files... It's a loss of information in
   some cases. I would be really worthwhile to have this feature
   **not only in a certain branch of the subversion code** but
   as a standard option for the normal SVN. I vote for this!
   Mike Brenner <mikeb_at_mitre.org> !!++
   Date: 2006-08-29 15:54:15 CEST
   "While many ftp servers do destroy the date, you can tar/zip
   before ftp-ing, or you can rcp. Under WINDOWS, the copy
   command does not destroy the date modified (although it does
   destroy the date created). I disagree that modification dates
   "are fairly useless". I often use modification data as an quick
   method of guessing the contents of files. In many configuration
   management systems the modification date serves as important
   metadata. Changing the data on a file strongly implies that
   the content has changed. When software gets more complex, we
   need to know whether we have the original version of a file
   or the changed version. Stability and debugging often depend
   on having an original, unmodified file for everything except
   the unit under test. We should evolve subversion towards
   keeping the modified date.
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-29 14:15:48 CEST
   "Well, there is the unofficial "text-time" branch of Subversion
   which does maintain this information. If maintaining this
   metadata is very important to you, you may want to build this
   branch of Subversion and use it instead of the official
   FWIW, I don't think the current Subversion behavior was created
   by accident or is considered a missing feature. Rather, I think
   it's intentional, to enable people to work with Makefiles in
   the standard way. I'm not sure I can explain it entirely
   correctly because I don't write compiled software...
   Andrew Webb <andrew.microi_at_gmail.com> !!++
   Date: 2006-08-29 15:36:24 CEST
   "I'd like to see an option to preserve files' last-mod dates
   in SVN 1.5. Then us Windows users can purge VSS from the planet
   forever. My intention is that this option would be for the
   benefit of me, of all Windows users, and hopefully also of
   SVN in reaching a wider, Windows audience." [[ 'enable people
   to work with Makefiles in the standard way' ]] "Umm... well,
   as a Windows developer, I would say it works the other way
   round. As Steve Fairhead says in a recent, related thread: 'one
   could argue just as hard for timestamps to be preserved
   *because* of makefiles'." Andrew
   Greg Thomas <thomasgd_at_omc.bt.co.uk>
   Date: 2006-08-29 16:01:12 CEST
   [on 'make']
   Henk Wissink <HenkWissink_at_Boschman.NL> !!++
   Date: 2006-08-29 16:03:54 CEST
   "Recently, I started the thread "How to convert specially
   set-up subdir tree into svn" to call for help on a few topics
   of which one was to avoid losing implicit information
   (like date/time stamps) in the process of filling a new SVN
   repository with the contents of my somewhat specially
   constructed version control directory tree I used for 15 years.
   Now I see in new threads that there are more people concerned
   about the loss of that information. But for this 'makefile'
   issue I would like to bring up the following. Let us say you
   check out a file dated 2 weeks ago... [...]
   Andrew Webb <andrew.microi_at_gmail.com>
   Date: 2006-08-29 16:38:22 CEST
   [more on 'make']
   Steve Fairhead <steve_at_fivetrees.com> !!++
   Date: 2006-08-29 19:34:34 CEST
   "... However: any time I do anything as drastic as checking
   files out of a VCS, or reverting, or including a replacement
   file from a colleague, or otherwise messing with the data
   that make uses to do a build, I'd expect to do a make clean
   or a touch. This is pretty basic stuff. It's not a reason
   for a VCS to throw data (in the form of timestamps) away."
   John Burwell <john.burwell.lists_at_galvnews.com> !!++
   Date: 2006-08-29 23:00:30 CEST
   [[not a reason for a VCS to throw data (in the form of timestamps) away.]]
   "For what it's worth, I likewise hate seeing information destroyed.
   Is it really up to SVN to accommodate make's behavior in protracted
   what-if scenarios? SVN is useful for all kinds of projects and
   document-management applications. I could make sense out of a
   checkout/update option that uses the check-in date as the last
   modified date on checked-out files, but a more intuitive default
   would be to preserve the file exactly as it was checked-in, which
   would include available metadata. I'd like to see date clobbering
   provided as an option for users who spend a lot of time dealing
   with the issues presented by make. The length and verbosity of the
   discussions on this list is clear enough evidence that people
   without an understanding of the make problem and its variants will
   likewise have no understanding of SVN's current default
   date-clobbering behavior. If SVN is to continue being promoted
   as a tool of versatility and flexibility, supporting the
   most general use cases by not clobbering file modification dates
   would be best, while allowing users with more specific requirements
   to take advantage of the options as needed would maintain SVN's
   Steve Fairhead <steve_at_fivetrees.com> !!++
   Date: 2006-08-29 23:44:22 CEST
   [['For what it's worth, I likewise hate seeing information destroyed.
   Is it really up to SVN to accommodate make's behavior in protracted
   what-if scenarios?']] "Well said. Seems to me that SVN's behaviour
   is defended here as a workaround for a problem that exists in
   collaborative s/w projects with/without a VCS system... Yes, there
   are problems with makefiles in group projects. It's not up to a
   VCS to work around them. And a VCS is more generally useful than
   in just those environments."
   Peter Werner <l.svn_at_vasas.no-ip.org> !!++
   Date: 2006-08-30 08:44:03 CEST
   "The problem is that svn is written in a compiled language, so
   they like to support make. [UNIX] cp does have a feature to
   preserve modification times, so it could be the same with svn
   (but never default behaviour). WP.
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 09:55:27 CEST
   "Yes, the Unix "cp" command works like that [by default], but
   copying a file in, say, the Mac OS X Finder does preserve the
   modification date, which is what Mac users expect, since it's
   been that way for 22 years so far and shows no signs of changing.
   (I don't know how Windows behaves in this regard.)" [* UNIX cp -p *]
   Gavin Lambert <gavinl_at_compacsort.com> !!++
   Date: 2006-08-30 00:34:26 CEST
   "If you're using SVN for document versioning (which AFAIK
   wasn't the original goal, but it's cool that it can be used
   that way) then it *might* be desirable to preserve timestamps,
   if you don't have a better way of keeping track of documents."
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 00:52:59 CEST
   "Well, for *compiled* software projects using Makefiles or
   similar, Subversion's current behavior is useful. For me,
   it's not, as I write web sites in PHP, which is interpreted,
   not compiled. I don't use Makefiles."
   Duncan Murdoch <murdoch_at_stats.uwo.ca> !!++
   Date: 2006-08-30 15:32:53 CEST
   "I'm just curious: how does the current behaviour cause trouble
   in this situation? In the only example I can think of (page
   reports "last change" date) it seems to me that you really
   would want checkout or update time shown, because that's when
   the page changed from the point of view of someone using the
   web site. The developer can look at the svn log to see when
   the page last changed in the repository. Of course, this
   ignores the loss of information when importing an existing
   project into SVN; is that the main concern? Duncan Murdoch
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 16:13:29 CEST
   "That is my main concern, yes. I can deal with having just
   commit times (as opposed to modification times) for files modified
   once the project is in source control, but I was unhappy to
   lose the modification time information for the years-old project
   I imported. It's a moot point for me now as I accepted the
   information loss and moved on, but for others just starting to
   use Subversion now, it becomes an issue again.
   Steve Fairhead <steve_at_fivetrees.com> !!++
   Date: 2006-08-29 20:15:05 CEST
   "Like others have said, I'm fairly used to gaining a quick idea
   of the state of play of the project by sorting by date. Some
   files are current; some may not have changed in years. I'm
   currently looking at a source file folder in which some font
   files were built back in the 80s. The last-modified-date
   timestamp is a useful piece of data which svn simply discards.
   As I said earlier, this rules out svn for production use for me/us.
   Seems a shame. So near, yet so b0rked..."
   Duncan Murdoch <murdoch_at_stats.uwo.ca>
   Date: 2006-08-29 22:25:30 CEST
   "I would guess that it wouldn't be impossible to write wrapper
   scripts for svn that put the last mod date into a property just
   before a commit, and then modified the date based on that
   property just after a checkout or update. Tricky decisions
   would be what to do if an update resulted in a merge (presumably
   keep the merge time as last mod time), and recognizing cases
   where someone checked something in without using your script
   (so you'd need to fall back to the commit time). Duncan Murdoch
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 00:51:55 CEST
   "The problem with that is obviously the initial import: If I'm
   importing a project that's been developed without version control
   over the past two years, I don't suddenly want all of the files
   in the project to have today's (or any other) modification date.
   I want each file to remember the date on which that file was
   modified. As has been explained by others, this is useful
   Steve Fairhead <steve_at_fivetrees.com> !!++
   Date: 2006-08-30 01:15:41 CEST
   [[ 'I want each file to remember the date on which that file was
   modified. As has been explained by others, this is useful
   information.' ]] "Quite. As a test, I've been doing just that,
   issue by issue, with an old, but still on-going, project.
   Issue 1 was in May 1990. SVN doesn't know this. The docs refer
   to SVN as being a file server with an added dimension: time.
   Ironic, really ;)."
   Andrew Webb <andrew.microi_at_gmail.com>
   Date: 2006-08-29 20:01:03 CEST
   "So... it seems that for some this proposed feature of
   retaining files' last-mod date is a must-have, and their
   processes, make procedures and so on can cope. For others,
   the opposite is true. Say for argument's sake it is implemented
   as an option in SVN 1.5. What form should the option take? Is
   this a affects-whole-repository flag? Or does it need to be
   more granular?"
   Steve Fairhead <steve_at_fivetrees.com>
   Date: 2006-08-29 17:01:08 CEST
   [[ 'That's the issue subversion's current behaviour avoids. Fine,
   get it added as an option, but please don't force me to use it.']]
   "In any case, it's becoming abundantly clear that "preserve
   original timestamp" should be a checkout option. As someone
   else has noted, consider the Unix "cp -p" precedent."
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2006-08-30 09:59:26 CEST
  "I think that you may be missing the point that people are trying
   to make, The no-one is using the modified date time to *guarantee*
   the file has not changed, but simply to give and indication that
   a file has changed and that if it has changed then roughly
   when did it change? Quoting Mike: [[ 'Similarly, for certain
   non-developmental, never-changing files that get configured
   in order to include them in the final product, changing the
   date makes it very weird to say this file bears today's date,
   but I promise you, no one has modified it in the last 5 years.' ]]
   This is what I see as one of the primary uses of this option
   to keep the modified date-times.
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 10:01:02 CEST
   [[ 'Now, if you could do a substitution of a keyword
   %FILEMODDATE% in an auto-prop, this would be easy.' ]]
   "Oh, I see. You're thinking of a versioned property, like what's
   used in the text-time branch. Yes, if you wrapped both commit/import
   and update/checkout to do the right thing in either direction,
   it sounds like that could work. I was thinking of an unversioned
   property, specifically the svn:date property of the revision, of
   which there's of course just one for the entire revision. If you
   check in (or import) multiple files in a single revision, they
   all have the same svn:date."
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2006-08-30 10:20:23 CEST
   "Surely another good approach would be to bring the text-time
   branch in line with the latest source, check that it still
   works as required (See
   and then incorporate it into the trunk!"
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2006-08-30 10:41:25 CEST
   "There was a design discussion a little while ago, This would
   probably be a good starting place to improve on if required.
   http://svn.haxx.se/users/archive-2005-11/1101.shtml "
   Duncan Murdoch <murdoch_at_stats.uwo.ca>
   Date: 2006-08-30 14:49:24 CEST
   "[as to] http://svn.haxx.se/users/archive-2005-11/1101.shtml
   I haven't read all the messages in that thread, they're broken
   up into several different places. But one problem with the
   recommendation is that it lacks a discussion of behaviour on
   updates. It gives these 4 options for export and checkout:
   [...] Updates are trickier, because the file in the working copy
   will have its own modification date. If the file has been
   modified since the last checkout, but a binary compare says
   there are no net changes: should the date be changed back to
   the old one? If it has no local changes but is being updated,
   which date should be used? If changes have been made so the
   update will do a merge, which date should be used? Duncan Murdoch
   Gale, David <David.Gale_at_Hypertherm.com>
   Date: 2006-08-30 14:43:28 CEST
   "Importing files doesn't change the modification time. Do an
   in-place import, and you'll have a working copy with all of
   your precious old modification dates intact; the mod dates will
   only be touched when you actually modify the file (or update a
   file that someone else has modified). -David
   Marko Kaening <mk362_at_mch.osram.de> !!++
   Date: 2006-08-30 15:12:38 CEST
   "Well, but if you add a file (which is the usual way of putting
   a new file into a repo, like in TortoiseSVN) the date is not
   preserved! :( " Marko.
   Duncan Murdoch <murdoch_at_stats.uwo.ca>
   Date: 2006-08-30 16:27:24 CEST
   "Right. There's an option somewhere to use commit time on
   the checkout, but the original modification time on the files
   never makes it into the repository. Duncan Murdoch"
   Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 15:32:42 CEST
   [[ 'Do an in-place import, and you'll have a working copy with
   all of your precious old modification dates intact...' ]]
   "Well, yes, but that applies only to that one local working
   copy. As soon as I check out a new working copy, or if someone
   else checks out a working copy, they don't see the original
   dates. They see either the current date or the import date,
   depending on whether they're using use-commit-times or not. I
   want the original modification dates preserved in the repository
   where they belong. Through use-commit-times or a similar option,
   users would still be free to select whether they want their
   working copies created with this additional metadata or not."
   From: Ryan Schmidt <subversion-2006c_at_ryandesign.com>
   Date: 2006-08-30 16:48:51 CEST
   "Right. Subversion does not preserve timestamps. That's the
   feature request this whole discussion is about. If you import
   a project, then the only timestamp Subversion stores is the
   timestamp when you imported, and that's stored in the
   resulting revision's svn:date property."

Timestamps / keeping last-modified dates
   Steve Fairhead <steve_at_fivetrees.com>
   Date: 2006-08-29 14:40:09 CEST
   "Simple version: is there now/yet a way of preserving the
   original file timestamps (not commit time, not checkout time,
   but last edit/changed time) when committing a bunch of changes?
   Longer version: for all sorts of good reasons, the last-modified
   timestamp of a file is an important piece of information that is
   being lost, it seems. I've read the rationale behind the
   commit-time thang, but I happen to not agree with it - or at
   least, it seems to me that such arguable behaviour should be
   configurable. Personally, I need that last-edited/built time.
   It matters to me. Consider me old-fashioned. Blunt version:
   if SVN can't preserve timestamps, it's doing less for me than
   a fileserver and the bunch of tar/zip/whatever files I have now.
   Sadly, it's of no use to me - yet. I shall have to resume my
   lonely, forlorn search for the One True VCS... Ok. I'm missing
   something obvious, right? I must be; this is fairly fundamental,
   and I don't believe svn can possibly be so b0rked in such a
   basic way - it's glorious in so many other ways."
   Andrew Webb <andrew.microi_at_gmail.com> !!++
   Date: 2006-08-29 15:49:40 CEST
   "SVN is at 1.4 RC stage. So 1.5 must be being planned. If this
   issue was sorted -- i.e. presented as a user option -- then truly
   I would consider SVN the One System To Rule Them All. I agree
   that this is a very fundamental issue, and one that should be
   determined one way or the other before other, more esoteric
   features are considered. With AnkhSVN reaching full 1.0 release
   any day now, things are really coming together for SVN on
   Windows. It's a good time to adopt, so long as we can get
   this last-mod issue sorted. Andrew.

   From: Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2006-08-30 09:46:17 CEST
   "I think that adding it as an option is all that people are
   asking for! Also to keep the current behaviour as default. It
   is the case that there are a lot of people that are interested
   in the modified date-time information for a variety of reasons,
   and the argument seems to be that these people should never
   need the modified time because it has been deemed useless. In
   reality there is no defining reason to use any of the
   methodologies on offer here, it simply comes down to personal
   preference, which I am sure that everyone can agree that we
   will never get a consensus on! Subversion should simply
   provide options to allow everyone to work how they feel most
   comfortable. It would be great if the trunk of subversion
   could already do this, but unfortunately it is still work in
   progress. See
   for the official bug about it. And search the archives for
   "Getting Bug 1256 fixed" as there was a recent (Nov 2005!)
   discussion about this, which was not the first discussion on
   this subject. -Graeme

Re: Enforcing date relationship between files in pre-commit hook
    Reid Priedhorsky <reid_at_umn.edu> !!++
    Date: 2006-09-08 03:03:52 CEST
   "I found plenty of information on finding which files were
    in the commit, and the timestamp of the commit (both using
    svnlook), but I couldn't locate info on last-modified
    timestamps of individual files in the commit. Could you
    give a more specific pointer into the documentation?
    Thanks very much, Reid
    Blair Zajac <blair_at_orcaware.com> !!++
    Date: 2006-09-08 04:09:25 CEST
    "The Subversion client doesn't send the file's last modified
    time to the server. Your best bet in this case is to do the
    test, if there's a commit to any of the .tex files, then
    the .pdf file must also be in the commit.
    Ryan Schmidt <subversion-2006c_at_ryandesign.com>
    Date: 2006-09-08 05:28:12 CEST
    "Oh. I'm sorry. I answered too quickly / didn't completely
    think about your question. Subversion doesn't store the
    modification date, so that's why you're not finding it. If
    it's essential to your plan, you can compile your own version
    of Subversion which does store the modification date. It's
    in the so-called "text-time" branch here:

[PROPOSAL] Versioning mtime
    Erik Huelsmann <ehuels_at_gmail.com> !!++
    Date: 2006-09-16 15:03:27 CEST
    [*** Major design document ***]

    "I've seen regular requests for versioning 'mtime's in the
    users list, so, given that we still have the metadata
    versioning branches living in our tree, I thought I'd try
    to flesh out a proposal for versioning this kind of metadata.
    All requests had the common denominator that recording of
    the mtime property was required. So here it goes:

    The problem:
    For various reasons people assign certain value to knowing
    the mtime value of files. Most of them know it's not the
    most exact indication of file modification you can get, but
    often times there are no other - quick - alternatives. In
    many situations, a habit like this has grown when shops
    come from a situation where there was complete lack of
    version control (other than the copy/paste kind). Subversion
    doesn't keep records of the mtime of a committed item at
    the time of committing, breaking the relation with historical
    methods of versioning...

    The proposed solution:
    Recording of mtime values for all node types (when
    applicable - but currently, we only have node types for
    which this is applicable) in a MTIME_RECORD* property
    upon request in the ~/.subversion/config file [*where
    the real name of the property can be chosen later].

    What this proposal isn't: This is not a proposal to add yet
    another set-the-file's-mtime-at-update option: simple
    wrappers can do that based on the infrastructure laid out
    in this proposal. That functionality may be an extention
    of this proposal, but it's not under discussion now.

    Behaviour of the client:

      * Import: The import command sets the MTIME_RECORD
        property for all committed items to the value found
        in the source directory at the time of import.
      * Checkout, Update, Switch: Any changes to the MTIME_RECORD
        will be integrated into the working copy.
      * Add: Add won't set the MTIME_RECORD property; commit
        will add it when the file is committed.
      * Copy, Move: Copy and Move won't preserve the
        MTIME_RECORD propetry unless explicitly instructed
        otherwise (just like *nix cp).
      * Commit:
         - Items without tree structure changes
           In this case, commit will bahave as Import, with the
           remark that merely a changed mtime itself is no
           reason for a node to end up in the list of
           committable items.
         - Tree changes through Add (without history)
           In this case, commit will behave as Import.
         - Tree changes through Copy and Move (Add with history)
           If an add-with-history item has an MTIME_RECORD
           property AND is content as well as property wise
           unmodified, the MTIME_RECORD property is unmodified
           and committed. In all other cases, the MTIME_RECORD
           property is set to the value found in the working copy.

    * Merge: This command will actively ignore any changes
      to the MTIME_RECORD property.

    * Export, Resolved, Revert, Switch -- relocate, Cleanup,
      Lock, Unlock, Diff, Log. These commands are not affected.

    Storage: The MTIME_RECORD property will be stored in the
    same format as the svn:date format.

    So... I'd like some comments to this proposal. Later, if
    this proposal is agreed upon to be a good document to work
    from, I hope to get some feedback on wether this is what is
    currently in the text-time branch. Please don't put that
    in this thread. bye, Erik.


Tortoise svn files date/time
   nicpav <nicpav_at_freemail.gr> !!++
   Date: 2006-09-22 10:17:40 CEST
   "Hello, I am using the Tortoise 1.4.0 and I am a new user. I
   would like to ask when I commit some changes the time of
   commited file changes to the current commit time. Is there
   a way to keep the original date/time values. Thanks in
   advance. nicpav
   Sven Brueggemann <SBrueggemann_at_gmx.net> !!++
   Date: 2006-09-25 20:21:54 CEST
   "But generally: No. Currently subversion does not version
   meta-data such as time stamps, attributes or access rights.
   Kind regards, Sven

RE: [PROPOSAL] Versioning mtime
    Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
    Date: 2006-10-03 15:45:10 CEST
    "There was a requirements discussion a little while ago.
    More comments below....
    Default to store the information because new subversion users
    will not consider that this sort of information is not
    stored and by the time that they come to look for it is will
    almost definitely be too late..." [***read more***]

Re: [PROPOSAL] Versioning mtime [ *** Design work *** ]
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2006-10-09 00:03:52 CEST
   "Judging from some of your reactions, the title of the proposal
    probably should have been 'Recording mtime'.
    Given that I'm working out a proposal for recording (but not
    setting) of mtimes, I think it should even work that way if
    the local mods disappear, yes. Because, in your comment, it
    looks to me like you think the mtime should be a 'maintained'
    value: just like we do with 'use-commit-times'.
   Ph. Marek <philipp.marek_at_bmlv.gv.at>
   Date: 2006-10-09 07:01:28 CEST
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2006-10-26 23:01:07 CEST
   Ph. Marek <philipp.marek_at_bmlv.gv.at>
   Date: 2006-10-27 12:03:19 CEST
   "Hello Erik! We seem to have the same opinion about most
   of the intended behaviour - so there's not much to argue
   left. In fact, I'd just like to [...]

File date/time
   Brian Erickson <erickson_at_BAUERCONTROLS.com> !!++
   Date: 2006-10-26 22:50:04 CEST
   "I imported our entire source tree with the following command...
   I then noticed that all of the files had today's date. Did
   it happen on the import or checkout? Is there any way to
   stop this horrible behavior?"
   Mark <mark_at_mitsein.net>
   Date: 2006-10-27 00:11:38 CEST
   Ryan Schmidt <subversion-2006d_at_ryandesign.com>
   Date: 2006-10-27 00:40:51 CEST
   "Subversion does not preserve modification times in the
   repository. It stores only the commit time. So this
   happened on import. When you check out, the files in
   your working copy will be modified "now". If you want
   instead to get the modification time to be the time the
   files were committed, set "use-commit-times = yes" in
   your client config file. If you must preserve each
   file's modification time in the repository, then you
   can consider compiling Subversion yourself from the
   unofficial "text-time" branch:
   Then you would need to start over, create a new
   repository, and import again. FWIW I would also find
   it useful if this were an option available in the
   standard Subversion, particularly for importing
   historical projects where the loss of such information
   can be significant. See this feature request:
   Oliver Betz <list_ob_at_gmx.net> !!++
   Date: 2006-10-27 08:55:15 CEST
   [[FWIW I would also find it useful if this were an option
   available in the standard Subversion, particularly for
   importing historical projects where the loss of such
   information can be significant. See..]]
   "ack. But most times it is sufficient to have the commit
   time set to the file mtime when importing the project the
   first time. I already posted a (crude) perl script to this
   list doing this... [script code]

Issue #1256 Preserving timestamps
   Greg Rundlett <greg.rundlett_at_oasis-open.org> !!++
   Date: 2006-11-02 01:42:27 CET
   "Hi all, There is an issue #1256 relating to preserving
   timestamps [1] which has been around for a long time,
   and has even had various patches proposed. It is my
   understanding that Subversion currently lacks support
   for preserving original timestamps of files imported
   into a project. This issue is marked as on the roadmap
   for the next release with the status 'NEW'... I'm
   wondering if anyone is actually working on it, and
   whether the solution will take care of my use case: I
   simply want to be able to import an existing filesytem
   tree (e.g. website files) that might have timestamps
   from a year ago such that when I do an svn checkout, I
   receive any *unmodified since import* files with the
   same mtime as the files that originally went into the
   project (in other words these files are still one year
   old). I would want to correctly show that files *modified
   since import* show the checkout timestamp. That way
   scripts, file managers or search tools etc. that are
   looking for 'new' files don't get the wrong impression
   about when these files were last modified. Maybe svn
   already does what I want and I've misread all the docs..."
   [1] http://subversion.tigris.org/issues/show_bug.cgi?id=1256
   Lieven Govaerts <svnlgo_at_mobsol.be> !!++
   Date: 2006-11-02 11:20:14 CET
   "This has come up on the dev list a few weeks ago, it
   seems that Erik has plans to start implementing it:
   (thread is split up in the archive) Check if the proposal
   in the thread covers your use case, if it doesn't add it
   as a reply to that thread. Note 1: from reading the
   thread it doesn't look like this is a simple feature, so
   don't expect this anytime soon. Note 2: The fact that the
   target milestone of the issue is 1.5 doesn't mean anyone
   is actively working on it and definitely doesn't mean
   it's on the roadmap for 1.5! Look at the history of the
   ticket and you'll notice that it has been moved since 1.2,
   waiting for a decent design discussion. hth, Lieven.
   Oliver Betz <list_ob_at_gmx.net>
   Date: 2006-11-02 12:49:30 CET
   "You can make the initial checkout with "use-commit-times"
   and later without. Not exactly what you described, but
   maybe what you want. Oliver.

[14] ======== Postings from 2007 ========

preserving date-time of files in repository
    Dave Nadler <Dave.Nadler_at_nadler.com> !!++
    Date: 2007-01-01 23:41:19 CET
   "How can I get subversion to preserve the date-time of a file
    when its checked into and out of the repository ? The real
    time-stamp of when the file was last *really* changed is an
    important piece of information, and we need to preserve this.
    Especially during migration to use of subversion!" Help ! I
    read the pragmatic book, searched the documentation, and
    cannot find out how to do this (or if it is indeed possible).
    Apologies if it is documented and I've somehow overlooked it...
    Thanks in advance, Best Regards, Dave - Dave Nadler, USA East
    Coast voice (978) 263-0097, drn_at_nadler.com
    Mike Brenner <mikeb_at_mitre.org> !!++
    Date: 2007-01-02 17:19:47 CET
    The "use-commit-times" specifically uses the time you
    committed into the library, as opposed to the time you last
    CHANGED the file. And it does not even do that! If you change
    a file in 1999, then you move it into subversion in 2005,
    then you take it out of subversion and re-check it into
    subversion in 2007, it will have the date 2007, not 2005. So
    it is not the time it last changed its check-in date into
    subversion, but rather the MOST RECENT check-in date into
    subversion. What subversion needs is the option to
    "use-file-modify-times" instead of commit times. If that
    option were to become available, then the first time someone
    started copying files around, they would see the problem and
    start using that "use-file-modify-times" option!
    Dave Nadler <Dave.Nadler_at_nadler.com>
    Date: 2007-01-03 01:06:46 CET
    Right Mike, thanks for clarifying. If a file was last edited
    back in 1991, we need the file timestamp to remain 1991 until
    somebody really changes it. Do I understand correctly that
    "use-file-modify-times" or equivalent just doesn't exist ?
    Thanks again, Best Regards, Dave
    Mike Brenner <mikeb_at_mitre.org>
    Date: 2007-01-03 15:56:10 CET
    "Hi Dave, Yes, you understand correctly. Subversion does not
    have any equivalent to "use-file-modify-times". Subversion
    destroys that information when it puts the file into the
    repository. When you "svn co" or "svn update", the bastardized
    file comes out of the repository with the modification date
    set to the commit date. In my opinion, this destruction of
    the most important information in a file (its modification
    date) constitutes the biggest design flaw in subversion. Svn
    serves its one use case well. Keeping the modification date
    intact would expand its usefulness to other use cases.
    Mike Brenner
    Dave Nadler <Dave.Nadler_at_nadler.com>
    Date: 2007-01-07 17:29:06 CET
    "OK, so how hard will it be to upgrade SVN to provide the
    "preserve-file-timestamps" option ? Is it completely impossible
    because the "DB" is hardwired with no provision for expansion
    and the concept is alien to all the SVN code ? Or would it be
    easy? Where can an SVN newcomer go to learn about the SVN
    architecture and how to attack this problem? Thanks in advance,
    Best Regards, Dave
    Erik Huelsmann <ehuels_at_gmail.com>
    Date: 2007-01-07 18:11:52 CET
    "Hi Dave, I have posted an IMO complete proposal for mtime
    recording at http://svn.haxx.se/dev/archive-2006-09/0492.shtml
    Search http://svn.haxx.se/dev/archive-2006-09/index.shtml and
    http://svn.haxx.se/dev/archive-2006-10/index.shtml for
    'versioning mtime' to find other people's reactions. I have
    stopped development of the feature before starting to implement
    the proposal (though nobody really objected, there was no active
    support either): other developers thought I could do better doing
    other work and in response, I cleared up ra_dav code instead
    (that's up for 1.5, but contains no visible changes for users).
    Anybody with sufficient time and motivation could implement the
    feature I have described though, I think. HTH, Erik.

Re: What do you Hate about Subversion?
    Mike Brenner <mikeb_at_mitre.org> !!++
    Date: 2007-01-18 22:33:52 CET
    [[ 'what are the things that you hate, you wish could be
    changed?' ]] "... c) tracking the last-modify-date of the
    files instead of just the checked-in date."
    Steve Bakke <steven.bakke_at_amd.com> !!++
    Date: 2007-01-18 23:01:13 CET
    "For c) I assume that you mean you'd like to see *both
    the checkin timestamp in addition to the last-modified
    timestamp. If so, I definitely agree."

date modified not accurate?
    Mike good_times <ukraine.believe_at_gmail.com> !!++
    Date: 2007-02-20 16:23:16 CET
    "1st time user, 1st time poster.... when viewing the up to
    date repository on my desktop, quite a few files have
    "date modified 2/15/2007 3:01pm". But when i view the log
    files, i see no one's updated these files from 2/15 to
    the present. and of course it's suspicious that numerous
    files would be modified @ the same time. they weren't
    recently added... what am I missing here? anyone know
    what probably happened? thanks in advance, mike.

Is there really no way to keep the file modification time intact?
    Frans Knibbe <frans_at_geodan.nl> !!++
    Date: 2007-02-26 14:30:28 CET
    "Hello, I have seen the subject pass by a few times in this
    list: subversion changes the file (modification) time to
    the commit time when you put a file in the repository. It
    is not possible to override this behaviour. I think is a
    fundamental problem with subversion. Whether I copy the file
    to another location, or compress it in an archive, or put
    it in a subversion repository, the time the file was last
    modified should not change. In other words: I think subversion
    should not tamper with files it stores. I want my files to
    come back exactly like they were when I put them in the
    repository. And that includes the time of the last modification.

    Now I have found that this problem is already an offcial issue.
    Its number is 1256
    But the issue has remained unresolved for a long time. I see
    it has now been postponed to version 1.5. I do hope this bug
    really gets solved soon.

    But I really can not wait for version 1.5. My organization
    is moving from another source control system to SVN and I
    have to write an importer. As it is now, it seems that all
    the files in the repository will wind up with the file time
    set to the moment they are handled by the importer. That
    means that a lot of useful and maybe vital information will
    get lost.

    Does anyone know of a way to put files in a subversion
    repository with the file time intact? Regards, Frans.

    Oliver Betz <list_ob_at_gmx.net>
    Date: 2007-02-26 15:01:29 CET
    "not exactly. You can set the commit time to the modification
    time when importing. See the perl script I posted 2006-10-27
    in the thread... I know that's not what you wanted, but
    maybe it's good enough for the moment. Nevertheless I also
    think that Subversion should support "mtime keeping" natively.
   Matt Sickler <crazyfordynamite_at_gmail.com>
   Date: 2007-02-26 21:44:08 CET
   "Sorry if I sound ignorant, but what does it really matter
    about the modification time of a file? What tools use it
    and why?"
   Frans Knibbe <frans_at_geodan.nl>
   Date: 2007-02-27 15:06:50 CET
   "First of all, I think it is a matter of principle. I think
   no information should be lost if I change the storage of my
   files. Of course, you could argue that the file modification
   time is not really part of the file itself, but some kind
   of metadata that can or can not be kept in the file system.
   I tend to view the file modification date as a file attribute,
   just like the name for example. I also do not want the
   name of my files to change or to disappear when I copy or
   move them.

   I really don't know which tools use the time and which don't.
   There probably are a few that use file modification time
   in some way. I know for sure my brain uses the file
   modification time. For example, if I see a file that was last
   modified in 1999, I know for sure that there aren't any
   calls to Windows Vista functions in that code. Also, I sort
   files on modification time a lot, just to see which files
   were recently edited.

   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2007-02-27 19:53:09 CET
   [[ 'Also, I sort files on modification time a lot, just to
   see which files were recently edited.' ]]
   "Right, but if we solve this issue, we'll need to determine
   whether a Subversion update to a file is a modification itself
   or not. Does an update to the file's metadata mean an update
   to the file itself? It's possible to change only metadata in
   a commit. For example: when you merge a change into your --
   otherwise unchanged -- working copy, which modification time
   do you assign to the file? That of the merge? That of the
   current time? Maybe the merge makes the file identical to some
   other file somewhere in the repository? What do we do then?
   Well, as you can see, versioning the modification time is
   not as simple as it may sound. bye, Erik.
   Frans Knibbe <frans_at_geodan.nl> !!++
   Date: 2007-02-28 12:07:24 CET
   "I think maybe the best way to look at it is to look at how
   Subversion handles other metadata. I think the file name also
   is metadata, but that is a special case because Subversion
   uses this as the file identifier, right? If I change the
   name of the file using the OS, subversion has lost track of
   the file. So maybe it is better to look at the execute bit
   as an example of comparable metadata. It is stored in the
   property svn:execute. As far as I understand, subversion sets
   this property to the right value on every commit and sets
   the execute bit right when a file is copied from the
   repository. I can not check this, as I am on Windows XP,
   which does not have execute bits for files. I think this
   would probably the best way to handle the file modification
   time. Define a new reserved property, something like
   svn:modification-time and have it automatically set on
   commits. I don't know if you just change a file's execute
   bit (on a UNIX or Linux system) this is reason for Subversion
   to create a new revision upon commit. But in the case of
   the file modification time, it probably does not matter
   because if the OS has changed this time, the file itself
   will have been modified. So a new revision will be needed
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2007-02-28 16:58:42 CET
   "Some time ago, there was an enhancement proposal on the
   developers list about versioning modified time metadata. If
   you're interested, you can find it in the archives at
   There was no implementation due to lack of (positive) reactions.
   [[I think this would probably the best way to handle the file
   modification time. Define a new reserved property, something
   like svn:modification-time and have it automatically set on
   commits.]] This is what the proposal was about. I suggest the
   following action:
    - I attach the proposal to issue #1256
    - everybody who is interested can add his/her username to the
      CC list
    - after an 8-week data-collection period, we can come back
      to this list and discuss the design again with those
      interested (including those on the issue CC list)
    - when the discussion comes to a conclusion, it'll the
      proposal may need adjusting
    - after adjusting, we'll want to find people wanting (to help)
      to implement the change (I'll have at most time to help
   Also, to the active developers this hasn't been much of an issue:
   each scratches his/her own itches, but nobody seems to have
   this itch. I can help coach someone wanting to jump into the
   codebase to help develop this feature, but I don't have time
   to do more either. bye, Erik.
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2007-02-28 12:33:05 CET
   [[ snip... the information is too fragile to be of any other
   value - as others have stated, many tools change it or maybe
   don't maintain it on copy or move.]] "One of which is subversion,
   making this a circular argument!"
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2007-02-27 10:55:59 CET
  "All people want, and there have been a lot of people asking,
   is the ability to preserve the modified time if they find
   this information useful."
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2007-02-27 11:07:02 CET
   "This is also the case using the mv command between different
   disks, separate file systems - does not exist in the target
   file system, yet the mv command preserves the modified time.
   By your argument the modification time shoud be set to the time
   of the move."
   Mike Brenner <mikeb_at_mitre.org>
   Date: 2007-02-27 12:42:01 CET
   "Excellent response, Graeme. To take it one step farther, the
   lost information about modified time hurts whenever the
   modified time is before the created time. In both windows
   and *nix systems, the most common ways of copying (mv, cp,
   move, copy, mouse-move, mouse-copy, winzip, xcopy, etc.) ALL
   preserve the modified date of the files. The real question
   should not be "which tools use the modified date", but "which
   tools do not use the modified date". Therefore, consider the
   Use Case of versioning log files (as opposed to source files).
   One would like to know the modification date of the file
   because the file's identity involves its last mod time. It
   would serve as a welcome short cut to finding the correct
   file (like a hash code) if svn would co the files with
   their original mod dates. Mike Brenner.
   Bob Hiestand <bob.hiestand_at_gmail.com>
   Date: 2007-02-27 16:34:23 CET
   [[ALL preserve the modified date of the files...]] "This is
   simply not true. It is, however, not really relevant to the
   question of whether SVN should be able to store modification
   Marko Kaening <mk362_at_mch.osram.de> !!++
   Date: 2007-02-27 11:21:19 CET
   "Hi, I also have a case where it would be important to keep
   the modification time. And I did ask the same question also
   on the cvs mailing list a while ago and got quite similar
   responses... If you use these version-control tools just for
   source code the date has no or only redundant information,
   but as soon as you use cvs or svn for more than only source
   code you may meet quite often cases where it indeed makes
   sense to have this FEATURE or OPTION. I personally think
   about data files where I want to keep the original timestamp.
   I vote for such an option! ;) Best regards, Marko.
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2007-02-27 20:35:35 CET
   "Nor do the Subversion developers believe the modified
   timestamp has any other value than 'being a heuristic to
   determine whether a file has locally changed'... the
   information is too fragile to be of any other value -
   as others have stated, many tools change it or maybe
   don't maintain it on copy or move..."
   Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
   Date: 2007-02-28 11:52:24 CET
    "You are right, it is not true, but they all have the OPTION
    to preserve the modified data times. It IS relevant to SVN
    as this is a piece of software that can, and has, been
    described as being able to be used as a 'versioned file
    system'. Surely SVN should keep with the philosophy of
    these programs and provide the OPTION to preserve the
    modification date time? We have the constant argument that
    the modification date time is unreliable, unfortunately this
    statement is driven by programs like subversion that throw
    this information away, thus making the modification date
    time unreliable..."
    Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
    Date: 2007-02-28 12:27:25 CET
    "Lots of other verison control systems handle this issue in
    a sensible fashion. Metadata describes the data in the file
    - metadata is items like: File name, File size, Modification
    data time. This metadata information should be preserved
    through the version control system. The modification date time
    should be the date time that the content was last changed.
    It is possible to have subversion change the content of the
    file on checkout, if this Is the case then the modification
    data time will only be accurate if it is set to the Time that
    subversion modified the content."

File date/time stamps seems unworkable
   Neville Franks <webinfo_at_getsoft.com> !!++
   Date: 2007-03-01 11:56:35 CET
  "I am baffled by the use of Date's in TSVN, which is likely
  a Subversion issue, not a specific TSVN issue. When I commit
  a file it uses the current system date/time for the file
  date in the repository and not the actual file date/time as
  it is for the file in the 'working copy'. If I then Checkout
  the file to another PC or folder or Update it on another PC
  its date/time isn't as per the original 'working copy' file
  date/time. This means the exact same file on different PC's
  have different time stamps, which messes up backups that
  utilize time stamps, and can mess up build processes. I've
  done some searching for info on this, but so far I've come
  up empty. Dazed and confused would be an understatement.

Re: File date/time stamps seems unworkable
   Andy Levy <andy.levy_at_gmail.com>
   Date: 2007-03-01 12:04:52 CET
   "It's fairly well-known and documented (and often discussed to
   death on the Subversion mailing list) that Subversion doesn't
   maintain last-modified dates as part of the versioned data.
   At one time there was a series of patches to do this and some
   other metadata, but I don't think it's maintained anymore.

   You can configure your client(s) to set the date/time of items
   in your WC to the time the files were committed by setting
   use-commit-times = yes in the [miscellany] section of your
   config file. Why are your backup tools (at least on Windows)
   relying on date/time to decide whether a file has been updated,
   instead of looking at the archive bit?

   If your build process is this sensitive to dates, I'd start
   worrying about how reliably it builds what you think it's
   building. The build tool I'm using (AnthillOS, for Java web
   apps) does a fresh checkout as its starting point for each
   build, so everything is always known to be clean from
   Subversion (nothing locally modified).
   Neville Franks <webinfo_at_getsoft.com> !!++
   Date: 2007-03-01 12:20:08 CET
   "Andy, Thanks for the prompt reply. I figured that this was
   probably how it works, but it just seems completely brain dead
   to me. I fully appreciate that there can be tricky issues handling
   time stamps across PC's and time zones, but at least give me
   the option to try and use the files last-modified time stamps.
   My previous Version Control System handled this as I would expect,
   so this has come as quite a nasty shock. I really don't want the
   exact same files on different PC's to have different time stamps,
   and I can't see that I'm being unreasonable. Backup programs
   preserve time stamps for a good reason and its like saying
   they might as well not bother. If I'd been aware of this and
   other issues I mentioned on my blog post
   I probably would have stayed with my previous VCS.
   Robert Roessler <robertr_at_rftp.com> !!++
   Date: 2007-03-01 12:59:16 CET
   "This used to really trouble me too... I still am sort of
   bugged because it *feels* like information (the "starting" datetime
   stamps) has been [arbitrarily] discarded. BUT, a couple of notions
   for you: Conceptually, when working with a content management system,
   it is not useful to use language (and I mean in writing or in your
   head) like "the exact same files on different PC's to have different
   time stamps" - because they are NOT the same file. There is a single
   canonical [versioned] copy of the file, and it exists as an
   abstraction in the repository... however it may actually be
   represented or stored. Anything outside the repo is in a working
   copy, and comparing one working copy to another directly is using
   dubious semantics - or at least probably not the semantics you
   think. ;) [...] The above are my informal viewpoints as a user that
   help me get through the day without being overly disturbed by the
   heinous crime of discarding perfectly good datetime stamps... ;)
   Robert Roessler
   Peter McNab <mcnab_p_at_melbpc.org.au> !!++
   Date: 2007-03-01 15:12:38 CET
   "... Avoid-avoid-avoid putting autogenerated files under revision
   control. Unless they are to be shared for special purposes its
   a recipe for lots of letters to the user's list.
    Date: 2007-03-03 12:43:38 CET
    "I also prefer to see the last-changed and/or committed
    date, because it provides me with a lot of useful
    information. Like, when was this file last changed?...

Re: Is there really no way to keep the file modification time intact?
   Frans Knibbe <frans_at_geodan.nl> !!++
   Date: 2007-03-01 15:18:45 CET
   [[ I did write a script to implement a post-checkout hook, but
   it is a server-side script, of course; it does not do anything
   on the client: http://www.ryandesign.com/svnhookdispatcher ]]
   "Thank you for your suggestions. I have done some testing and I
   think I will choose the option to set the system time to the
   file modification time before each commit. It is a simple
   solution and I think it is sufficient for our purposes. All
   migrated files will have recorded commit times equalling file
   modification times. All future changes will just have a commit
   time, but this time will not differ much from the file
   modification time if users don't wait too long before comitting.
   Cheers, Frans.
   Les Mikesell <lesmikesell_at_gmail.com>
   Date: 2007-03-01 15:37:26 CET
   [[change system time]]
   "That sounds absolutely horrible in any scenario that could
   possibly have multiple users or concurrent commits happening at once.
   Frans Knibbe <frans_at_geodan.nl>
   Date: 2007-03-01 16:14:17 CET
   "Yes, it sounded horrible to me too at first. But I am running
   the migration to local Subversion repositories, one file
   revision at a time. After the migration is finished, other
   users will be given access to the repository..."
   Ryan Schmidt <subversion-2007a_at_ryandesign.com>
   Date: 2007-03-03 04:34:53 CET
   "Subversion simply does not store a modification date/time per
   file/ directory. It only stores the time that you commit a
   revision. Whether that's "wrong" or not is debatable. For some
   applications, obviously, it hasn't been a major problem, or else
   it would have been changed by now." [[ I agree it should be an
   option. ]] "I would like the option to store the modification
   date/time as well." [[ There should also be an option to have
   the file check out with today's date, the modification date, or
   the check in date, in my opinion. I find all 3 useful in
   different scenarios. ]] "The default is currently to check out
   with today's date. You can set use-commit-times=yes to get
   the check in date. You cannot currently get the original
   modification date/time because Subversion does not store that
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2007-03-03 07:57:10 CET
   Eric <spamsink_at_scoot.netis.com> !!++
   Date: 2007-03-03 15:12:16 CET
   [[ 'Subversion simply does not store a modification date/time
   per file/directory. It only stores the time that you commit
   a revision.' ]] -- "Good morning, Ryan. We all (well, at least
   those of us who have been following this thread) know this
   and understand it.

   What we are saying is that the inability of Subversion to
   store modification date/times is A Growing Problem for A
   Large And Growing Number Of Subversion Users. In our case,
   it's a major aggravation that we have resigned ourselves to
   for the foreseeable future, except that it's yet another
   arrow in the quiver of that one user I have discussed in
   the past, who considers Subversion a toy that's not suitable
   for serious developers.

   I consider that, and the inability to check out and check in
   individual files within a directory, as being the ONLY two
   near-show-stoppers ... EVERY other real or perceived
   shortcoming of Subversion is of medium concern at worst, and
   mostly they're all minor and not anything we're concerned about
   .. in fact if you asked me to list them I'd be hard-pressed
   to do that (I really am easy to please). :-)

   If I had to pick one of those two to be fixed, I'd pick
   the preservation of the file modification date/times, and
   live forever with the inability to check out individual files.
   I realize that Subversion is free and no one appreciates the
   hard work of the Subversion developers more than I do, but
   if you all could see your way clear to fix that one thing,
   you would have my undying gratitude ... well, actually,
   you already have that... :-)
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2007-03-06 11:01:04 CET
   "You can find the bug at:
   We don't pay attention to the length of the cc list (in general),
   but it does give me an opportunity to reach those who have
   expressed interest more specifically than sending an
   untargetted e-mail to this list. Anybody is free to cast votes
   as they like of course. When I'm looking for the amount of
   interest in an issue, I do look for signs of interest. This
   includes votes, cc-list length and number of different people
   commenting on the issue. But that only works when I'm
   interested in solving the issue, not for issue selection (ie,
   it's not like I'm going to select the issue with the most
   votes to work on).
   John Gwinner <jgwinner_at_dazsi.com> !!++
   Date: 2007-03-07 01:03:18 CET
   "Well, I may be putting myself in harms way, o.O but I'd
   venture to say that anyone thinking of migrating from
   SourceSafe will expect the check in time to be file
   modification time. They may or may not post on this list."

retroactive mtime versioning
   Aryeh Leib Taurog <AryehLeib_at_AryehLeib.com> !!++
   Date: 2007-03-25 20:21:03 CEST
   "I've been reading the discussion of versioning mtime
   and have added myself to the cc list for issue 1256.
   This has just become an issue for me, so I'm glad to see
   it is for others as well. I'm a newbie (I switched from
   cvs to svn about 5 months ago). So, although this is much
   related to the earlier thread
   this seemed a sufficiently different topic to start a new thread.
   As a consultant, I work mostly on a remote machine at my
   client's site, but I keep my own local svn repository. The
   clients integrate my work into their own code base using
   the files I put on their machine. When I started this job,
   I checked their entire code-base into my local repository.
   Only later did I discover that the import/checkout process
   reset the mtime of all my files. The only major issue for
   me was synching changes I make on my local machine
   with those on the remote machine and vice-versa. I figured
   I would just go ahead and reset all the mtimes on the remote
   machine as well... Then I heard from the client. They *must*
   have the original mtimes (for files I don't modify, obviously).
   Ryan Schmidt <subversion-2007a_at_ryandesign.com>
   Date: 2007-03-26 00:30:50 CEST
   "You cannot reset mtimes because Subversion never stores the mtimes."

svn import/commit doesn't preserve file timestamp
   Nathan Bates <nathanbates99_at_yahoo.com> !!++
   Date: 2007-05-11 07:00:37 CEST
   "We have a very strong need for a file's timestamp to
    be preserved in svn's repository. For example, we
    have old src files and design docs, but when they
    were imported, the files received the current time,
    which caused us to think they were updated by a
    developer. We had to stay with CVS because of this
    Ryan Schmidt <subversion-2007b_at_ryandesign.com>
    Date: 2007-05-11 10:37:43 CEST
    "You are correct. Subversion does not preserve timestamps
     on import or commit. The Subversion developers are aware
     of this and I don't believe it's a high priority for
     them to offer the ability to preserve this information,
     much as I would also like for them to do so. There are
     just several other features which are important to more
     people, and developer resources are limited." I believe
     there is a script floating around that provides a
     workaround. I think it imports each file as a separate
     revision and then sets that revision's svn:date property?
     I'm not sure because I've never used it, and I can't
     remember what it's called, but I'm sure someone else
     will remember it and chime in.

    Oliver Betz <list_ob_at_gmx.net> [Oliver Betz, Muenchen]
    Date: 2007-05-15 08:34:31 CEST
    "I posted a Perl script doing this, it should be in
    the archives
    But it's intended only for the initial import. During
    normal work I'm using the commit time."

Re: retroactive mtime versioning
   Aryeh Leib Taurog <AryehLeib_at_AryehLeib.com> !!++
   Date: 2007-05-29 23:51:34 CEST
   [ Ryan Schmidt wrote:
      [Then I heard from the client. They *must* have the
      original mtimes (for files I don't modify, obviously).]
      If you want to store modification times of each file,
      I see two options. One, you can commit each file as
      a separate revision, then set the svn:date property
      of the just-committed revision to match what the mtime
      of the file was. Repeat for all files.
      Or two, you can attach a new property (e.g. x-mtime)
      to each time. Set that property to the actual
      modification time of the file. Perhaps invent a script
      which handles the commit, by attaching the property and
      then calling svn ci. Invent another script to replace
      svn checkout, which checks out, and then also sets
      the actual mtimes of the files as per the contents of
      the new property.
   Ryan Schmidt <subversion-2007b_at_ryandesign.com>
   Date: 2007-05-30 00:16:31 CEST
   "It has been done before: the text-time branch:
   Unfortunately that code hasn't been touched in two years.

Subversion, binary files, hex editors and file modification time
   Oliver Paulus <oliver_at_code-project.org>
   Date: 2007-06-11 13:53:29 CEST
    [*** different issue about mtime -- not storing it per se ***]
    "I have the following problem: If a program like a hex
    editor does not change the file modification time SVN
    does not detect changes made to the file."
    "FSVS uses a subversion repository for storage, and it has
    a parameter "-C" that tells it to *always* check the MD5
    sum for changes (like rsync)."
     "As part of the solution to issue 2746, Erik added the
     ability to use file size as an additional indicator of
     modification. So, if you change the size of the file, but
     not the modified time, Subversion will be smart enough to
     know that the file was modified. IIRC, this has not
     been backported to the 1.4.x line, and will appear in
     Subversion 1.5."
   Peter Samuelson <peter_at_p12n.org>
   Date: 2007-06-17 04:18:08 CEST
   "It boils down to the question: what does mtime mean? Does it
   mean the last time the file was modified, not counting things
   like backup/restore? Or is it supposed to be a field used
   purely for human information, set to a time that humans might
   or might not consider sensible based on other context? (Such
   as "copied/converted/compiled/rendered/collated/encrypted/
   stripped/paraphrased from a file whose mtime was...")

   Todd Cosgrove <tcosgrov_at_gmail.com> !!++
   Date: 2007-07-12 14:27:10 CEST
   "Is it possible to set a property on a specific file to
    have it maintain it's last modified time...i.e. so
    that when someone checks it out or updates it, it
    doesn't get the current timestamp?

Can original file modification times be maintained?
   Tom Malia <tommalia_at_ttdsinc.com> !!++
   Date: 2007-09-06 15:39:26 CEST
   "One thing I use to rely on as a quick visual queue to what
   has been happing on a project is the modification dates
   on the files. Since moving to Subversion, this is something
   I really miss. Whenever I check anything out of subversion,
   all the files checked out have the exact same modification
   date which actually has nothing to do with when they were
   "actually modified". Is there any way to preserve the "true"
   modification date/time information for file that are
   maintained in subversion? Thanks in advance, Tom Malia
   Andy Levy <andy.levy_at_gmail.com> !!++
   Date: 2007-09-06 16:17:22 CEST
   "Set use-commit-times = yes in the miscellany section of your
   configuration file and you should get the local timestamp
   set to when the last commit for each file was performed when
   you checkout/update. If you want to keep the actual timestamp
   upon commit, that's an oft-requested, but as-yet-unimplemented

maintaining file modified dates during svn import?
   Reuben Avery <reuben_at_swirl.net> !!++
   Date: 2007-09-20 21:37:30 CEST
   "hi all, I need to be able to maintain the modified
   dates on files during an svn import. anyone know how to
   go about this? currently, the file date always gets
   set to the current date during an import. this is
   problematic for me as i am trying to mirror a client's
   website into the subversion repository but need to
   maintain those dates for reporting and site mirroring
   purposes. thanks for any tips, reuben
   Ryan Schmidt <subversion-2007b_at_ryandesign.com>
   Date: 2007-09-20 23:15:01 CEST
   "Subversion does not offer this feature. A Subversion
   repository does not store individual modification
   dates on a file and directory basis. Rather, each
   commit has a date/timestamp." To achieve what you want,
   you would have to employ a workaround, such as:
   * Import each file separately, in its own revision, in
     modification date/time order. After importing each file,
     set the svn:date property of that revision to the
     modification date/time of the file.
   * On each client, you'd need to use the "use-commit-times"
     option so that when you check out, the file's modification
     time gets set to the time it was committed, instead of
     the current time as is the default.
   Yes, this is a bit inconvenient. I believe someone may
   have written a script to automate the laborious importing
   process if you're interested, but I'm not sure where it
   is. Maybe someone else remembers.

PVCS to Subversion Migration Problem
   Adjei, Jeffrey <Jeffrey.Adjei_at_landg.com> !!++
   Date: 2007-10-11 12:56:42 CEST
   "Can someone please tell me how to migrate code from PVCS
   (Serena) into Subversion without losing the "modified"
   date of the files?
   Erik Huelsmann <ehuels_at_gmail.com>
   Date: 2007-10-11 13:38:20 CEST
   "Probably not: Subversion doesn't version the 'last modified'
   date. bye, Erik.
    Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
    Date: 2007-10-11 14:12:21 CEST
    "We also migrated from PVCS version manager to Subversion.
    The whole process on the whole went very smoothly, with the
    biggest difficulty being getting used to the change in
    terminology and the concepts of working copies. With direct
    regards to preserving the modified date times, the design of
    subversion means that the modified date times are not as
    important as you are able to reference the state of a folder
    using just the URL and revision number. In PVCS we used to use
    the modified date times primarily as they were a more trusted
    way of identifying a file. (And yes you can use MD5 hashes etc.
    but this is what we USED to do....) There are still occasions
    when preserving the modified date time is useful/essential
    and these have been discussed on many occasions in the history
    on this list and a bug
    has been raised to get this feature added.

Subversion, date/time question on initial import or add
   Andy <ANDREW.LUCAS_at_L-3Com.com> !!++
   Date: 2007-11-13 16:01:19 CET
   "Is there a way to keep the date/timestamp associated with
   files in the windows environment when initially setting up
   a new subversion repository? It seems to use the current
   date and time versus the date and time of the file? Could
   this just be our older version mix of the tools? (svnserve,
   subversion 1.4.2, wxWidgets 2.6.3, rapidsvn 0.9.4)
   Thanks in advance, Andy
   Ryan Schmidt <subversion-2007b_at_ryandesign.com>
   Date: 2007-11-13 22:42:19 CET
   "Subversion does not store files' modification/creation date/time.
   It only stores the commit time of the revision as a whole.
   When you check this out again later, two behaviors are possible.
   The default is that the modification date/time of all files is
   set to "now". The other option is that the date/time of all
   files is set to their commit time; to get this behavior, set
   "use-commit-times yes" in the [miscellany] section of your
   ~/.subversion/config (or wherever the equivalent file is on
   Windows, if you're using Windows). To get the behavior you
   desire, you would have to import each file as a separate
   revision, in chronological order, and then change the svn:date
   property of each revision to match that file's modification
   date. This would be rather tedious. You could write a script
   to automate this. Maybe someone has already written such a
   Lorenz <lorenznl_at_yahoo.com> !!++
   Date: 2007-11-14 09:30:42 CET
   [Is there a way to keep the date/timestamp associated with
   files in the windows environment when initially setting up
   a new subversion repository?] "if you only need the original
   date/timestamp for informational purpose you could set a
   custom property before commiting. have a look here

[15] ======== Postings from 2008 ========

Any progress toward "preserve timestamps"
   Michael Hipp <Michael_at_Hipp.com> !!++
   Date: Tue, 22 Jan 2008 09:17:15 -0600
   "After much searching I realize svn doesn't preserve file
   timestamps. Does anyone know if there is any development
   progress toward this feature? I find myself with several
   projects where file timestamps are valuable information to
   the humans, if not to the VCS. The 'use-commit-times'
   setting is a considerable improvement, but having the
   timestamp changed upon commit still represents a loss of
   information. Any progress toward this or any workarounds?
   Thanks, Michael Hipp
   Thompson, Graeme (GE Infra, Aviation) <Graeme.Thompson_at_ge.com>
   Date: Tue, 22 Jan 2008 11:24:12 -0500
   "There has been very little on the mailing lists recently
   regarding this topic
   The developers are working hard towards the 1.5 release and I
   doubt that this will make it (as it is P3, and there is no one
   currently assigned the bug....), but then it never quite made
   it into 1.0, 1.1, 1.2, 1.3 and 1.4 either ;-) I hope that
   someone will pick this issue up soon, but there is certainly
   some great new functionality coming with 1.5! HTH, Graeme

File time stamps on initial import
   George Reeke <reeke_at_mail.rockefeller.edu> !!++
   Date: Mon, 10 Mar 2008 12:13:13 -0400
   "Hello, I am new to SVN, so I'd appreciate a pointer to the answer
   if this is a well known problem. I just installed subversion 1.4.6
   on my RedHat EL 4 system. I read the book. I made a repository with
   svnadmin create. I imported my existing project into it with SVN
   import (using the svn server and the FSFS store). I did the
   initial checkout with svn checkout.

   To my horror, the time stamps on all my files were updated to the
   time when I did the import. I realize it's not really important
   any more what those time stamps were, except this project has
   been going on for many years and I would like to be able to see
   when I last worked on a particular file.

   So: Right now, while it's not too late to delete the whole
   repository and start over with another copy of my project, can
   someone tell me how to import a project into a repository and keep
   the original time stamps? When I make changes and commit them,
   then of course the time stamps should be updated accordingly.
   Thanks, George Reeke
   Paul Koning <Paul_Koning_at_dell.com>
   Date: Mon, 10 Mar 2008 12:20:30 -0400
   "Subversion doesn't preserve timestamps. - paul"
   Thompson, Graeme (GE Infra, Aviation) <Graeme.Thompson_at_ge.com>
   Date: Tue, 11 Mar 2008 10:12:31 -0400
   "Unfortunately, Subversion does not yet support the storage of
   timestamps.... It is a well documented bug / feature request:
   There are a couple of work arounds (That I think are referenced from
   the bug entry) of which the most popular is to wrap the commits with
   scripts to store the last modified timestamp as a versioned property,
   however I do not believe that anyone has ever posted their commit
   and update scripts to this mailing list, perhaps someone would be
   able to? HTH, Graeme
   Lorenz <lorenznl_at_yahoo.com> !!++
   Date: Wed, 12 Mar 2008 07:32:31 +0000
   "so if I get you right, your only interested to to preserve the
   pre-subversion timestamps? In that case I would "ls * > tempfile"
   and "svn propset LastModifiedTimestamp --revprop -r ImportRev
   --file tempfile repoURL" You could also, as Graeme mentioned
   already, use a versioned property. In that case a would add an
   empty directory to the repository first, check it out over your
   import folder, 'svn add' all files, set the custom property on
   all files and finally commit. If you are only interested to
   preserve the original timestamps of the imported files and not
   plan to update the properties on each commit, I would then
   remove the properties again and commit again. Otherwise you are
   stuck with the original value for ever. Might be irritating
   8-) Lorenz.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-13 09:48:24 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.