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]:
http://www.cpan.org/modules/by-module/Apache/DROLSKY/?M=D
http://www.cpan.org/modules/by-module/Apache/DROLSKY/?M=A
http://www.cpan.org/modules/by-authors/Tim_Bunce/?M=A
http://www.cpan.org/modules/by-authors/Tim_Bunce/?M=D
http://redvip.homelinux.net/varios/?C=M;O=D
http://redvip.homelinux.net/varios/?C=M;O=A
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
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
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,
fransk,graemethompson,gwagenknecht,janhendrik,jgwinner,kaening,kaitou,
kilobyte,muthm,obetz,ryandesign,sallycert,sharebird,talden
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
commit."
- 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:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=257080
(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:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=72777
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
time.
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:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=82422
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:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=82866
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
http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/text-time
and not the patches. There's a readme at:
http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/
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:
http://svn.haxx.se/users/archive-2005-11/1101.shtml
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:
http://svn.haxx.se/dev/archive-2006-10/0193.shtml
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:
http://angband.pl/svn/svnt/trunk/svnt
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]
draft-ietf-httpbis-p4-conditional-02
Section 7.6. Last-Modified
"For files, it may be just the file system last-modified time."
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p4-conditional-02.txt
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
http://svn.haxx.se/dev/
http://svn.haxx.se/users/
http://svn.haxx.se/tsvn/
http://svn.haxx.se/tsvnusers/
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 ========
http://svn.haxx.se/dev/archive-2001-06/0216.shtml
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
http://svn.haxx.se/dev/archive-2002-10/0838.shtml
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
http://svn.haxx.se/dev/archive-2002-11/0602.shtml
http://svn.haxx.se/dev/archive-2002-11/0936.shtml
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."
[ctime/mtime]
http://svn.haxx.se/dev/archive-2002-11/0983.shtml
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.]
http://svn.haxx.se/dev/archive-2002-11/0937.shtml
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.]
http://svn.haxx.se/dev/archive-2002-11/1058.shtml
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 :)
http://svn.haxx.se/dev/archive-2002-11/1068.shtml
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 :-).
http://svn.haxx.se/dev/archive-2002-11/1072.shtml
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
reasons.
[9] ==== Milestone: Initial discussions on SVN (not) storing timestamps ====
file times
http://svn.haxx.se/dev/archive-2002-12/0346.shtml
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
http://svn.haxx.se/dev/archive-2002-12/0350.shtml
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. :-)
http://svn.haxx.se/dev/archive-2002-12/0354.shtml
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"
http://svn.haxx.se/dev/archive-2002-12/0356.shtml
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.)
http://svn.haxx.se/dev/archive-2002-12/0357.shtml
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 ========
http://svn.haxx.se/dev/archive-2003-01/1754.shtml
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
http://svn.haxx.se/dev/archive-2003-04/0859.shtml
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
http://svn.haxx.se/dev/archive-2003-04/1024.shtml
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.
http://svn.haxx.se/dev/archive-2003-04/1026.shtml
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
http://svn.haxx.se/dev/archive-2003-04/1028.shtml
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
http://svn.haxx.se/dev/archive-2003-04/1062.shtml
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
constraints:
* There are reasons to want to preserve timestamps across
an import and checkout, e.g. if you're checking in generated
files and you want your build system to know that it doesn't
have to regenerate those files.
* On the other hand, if a checkout or update munges timestamps,
you run the risk of fooling a build system into thinking a
file hasn't been modified when it has.
* 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.
http://svn.haxx.se/dev/archive-2003-05/0377.shtml
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
http://svn.haxx.se/dev/archive-2003-05/0379.shtml
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
http://svn.haxx.se/dev/archive-2003-05/0516.shtml
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
(http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
but I'm afraid that post-1.0 is a bit late :-) Now I found
the discussion on
http://www.contactor.se/~dast/svn/archive-2002-12/index.shtml#346
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).
http://svn.haxx.se/dev/archive-2003-05/0532.shtml
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.)"
http://svn.haxx.se/dev/archive-2003-05/0536.shtml
http://svn.haxx.se/dev/archive-2003-05/0646.shtml
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.
http://svn.haxx.se/dev/archive-2003-05/0561.shtml
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.
http://svn.haxx.se/dev/archive-2003-05/0687.shtml
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.
http://svn.haxx.se/dev/archive-2003-05/1360.shtml
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."
http://svn.haxx.se/dev/archive-2003-05/1398.shtml
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
http://svn.haxx.se/dev/archive-2003-05/1403.shtml
http://svn.haxx.se/dev/archive-2003-05/1514.shtml
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.
http://svn.haxx.se/dev/archive-2003-05/1527.shtml
http://svn.haxx.se/dev/archive-2003-05/1404.shtml
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
http://svn.haxx.se/dev/archive-2003-05/1409.shtml
http://svn.haxx.se/dev/archive-2003-05/1741.shtml
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!
http://svn.haxx.se/dev/archive-2003-05/1762.shtml
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
http://svn.haxx.se/dev/archive-2003-05/1790.shtml
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??
http://svn.haxx.se/dev/archive-2003-05/1844.shtml
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 :-)
http://svn.haxx.se/dev/archive-2003-05/1797.shtml
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
http://svn.haxx.se/dev/archive-2003-06/0646.shtml
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
http://svn.haxx.se/dev/archive-2003-06/0647.shtml
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 :-)
http://svn.haxx.se/dev/archive-2003-06/0957.shtml
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,
Norbert
http://svn.haxx.se/dev/archive-2003-06/0963.shtml
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??
http://svn.haxx.se/dev/archive-2003-06/1210.shtml
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
http://svn.haxx.se/dev/archive-2003-06/0988.shtml
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 :-)
http://svn.haxx.se/dev/archive-2003-06/1106.shtml
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)
http://svn.haxx.se/dev/archive-2003-06/1113.shtml
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**]
http://svn.haxx.se/dev/archive-2003-06/1114.shtml
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).
http://svn.haxx.se/dev/archive-2003-06/1115.shtml
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...
http://svn.haxx.se/dev/archive-2003-06/1116.shtml
"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
http://svn.haxx.se/dev/archive-2003-06/1127.shtml
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."
http://svn.haxx.se/dev/archive-2003-06/1117.shtml
http://svn.haxx.se/dev/archive-2003-06/1129.shtml
http://svn.haxx.se/dev/archive-2003-06/1121.shtml
http://svn.haxx.se/dev/archive-2003-06/1139.shtml
http://svn.haxx.se/dev/archive-2003-06/1122.shtml
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
http://svn.haxx.se/dev/archive-2003-06/1142.shtml
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."
http://svn.haxx.se/dev/archive-2003-06/1208.shtml
[** long posting, summarizes P's work to date **]
http://svn.haxx.se/dev/archive-2003-06/1217.shtml
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. :-)"
http://svn.haxx.se/dev/archive-2003-06/1220.shtml
http://svn.haxx.se/dev/archive-2003-06/1288.shtml
http://svn.haxx.se/dev/archive-2003-06/1412.shtml
http://svn.haxx.se/dev/archive-2003-06/1414.shtml
http://svn.haxx.se/dev/archive-2003-06/1265.shtml
http://svn.haxx.se/dev/archive-2003-06/1268.shtml
http://svn.haxx.se/dev/archive-2003-06/1275.shtml
http://svn.haxx.se/dev/archive-2003-06/1467.shtml
http://svn.haxx.se/dev/archive-2003-06/1497.shtml
http://svn.haxx.se/dev/archive-2003-06/1521.shtml
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.
http://svn.haxx.se/dev/archive-2003-06/1524.shtml
http://svn.haxx.se/dev/archive-2003-06/1525.shtml
http://svn.haxx.se/dev/archive-2003-06/1527.shtml
http://svn.haxx.se/dev/archive-2003-06/1528.shtml
http://svn.haxx.se/dev/archive-2003-06/1530.shtml
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 ;-)
http://svn.haxx.se/dev/archive-2003-06/1533.shtml
http://svn.haxx.se/dev/archive-2003-06/1531.shtml
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.
http://svn.haxx.se/dev/archive-2003-06/1534.shtml
http://svn.haxx.se/dev/archive-2003-06/1536.shtml
http://svn.haxx.se/dev/archive-2003-06/1539.shtml
http://svn.haxx.se/dev/archive-2003-06/1529.shtml
http://svn.haxx.se/dev/archive-2003-06/1540.shtml
http://svn.haxx.se/dev/archive-2003-06/1542.shtml
http://svn.haxx.se/dev/archive-2003-06/1543.shtml
http://svn.haxx.se/dev/archive-2003-06/1544.shtml
http://svn.haxx.se/dev/archive-2003-06/1545.shtml
http://svn.haxx.se/dev/archive-2003-06/1546.shtml
http://svn.haxx.se/dev/archive-2003-06/1549.shtml
http://svn.haxx.se/dev/archive-2003-06/1550.shtml
http://svn.haxx.se/dev/archive-2003-06/1555.shtml
http://svn.haxx.se/dev/archive-2003-06/1551.shtml
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.
http://svn.haxx.se/dev/archive-2003-06/1554.shtml
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.
http://svn.haxx.se/dev/archive-2003-06/1568.shtml
http://svn.haxx.se/dev/archive-2003-06/1572.shtml
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."
http://svn.haxx.se/dev/archive-2003-06/1599.shtml
http://svn.haxx.se/dev/archive-2003-06/1607.shtml
http://svn.haxx.se/dev/archive-2003-06/1608.shtml
http://svn.haxx.se/dev/archive-2003-06/1609.shtml
http://svn.haxx.se/dev/archive-2003-06/1570.shtml
http://svn.haxx.se/dev/archive-2003-06/1573.shtml
http://svn.haxx.se/dev/archive-2003-06/1574.shtml
http://svn.haxx.se/dev/archive-2003-06/1604.shtml
http://svn.haxx.se/dev/archive-2003-06/1522.shtml
http://svn.haxx.se/dev/archive-2003-06/1526.shtml
http://svn.haxx.se/dev/archive-2003-06/1535.shtml
http://svn.haxx.se/dev/archive-2003-06/1658.shtml
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! |-\
http://svn.haxx.se/dev/archive-2003-06/1307.shtml
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
users.
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.
Yuck.
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
http://svn.haxx.se/dev/archive-2003-07/0167.shtml
[*** 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."
http://svn.haxx.se/dev/archive-2003-07/0168.shtml
http://svn.haxx.se/dev/archive-2003-07/0176.shtml
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 ..."
http://svn.haxx.se/dev/archive-2003-07/0190.shtml
RE: saving files' time stamps
http://svn.haxx.se/dev/archive-2003-07/0214.shtml
http://www.contactor.se/%7edast/svn/archive-2003-06/0988.shtml
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:
http://subversion.tigris.org/issues/show_bug.cgi?id=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
http://svn.haxx.se/dev/archive-2003-07/0740.shtml
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
http://svn.haxx.se/dev/archive-2003-07/0751.shtml
timestamp stuff, issue 1445
http://svn.haxx.se/dev/archive-2003-09/0209.shtml
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.
http://svn.haxx.se/dev/archive-2003-09/0210.shtml
http://svn.haxx.se/dev/archive-2003-09/0211.shtml
[corr:]
"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.
http://svn.haxx.se/dev/archive-2003-09/0218.shtml
http://svn.haxx.se/dev/archive-2003-09/0212.shtml
http://svn.haxx.se/dev/archive-2003-09/0317.shtml
http://svn.haxx.se/dev/archive-2003-09/0335.shtml
SVN import behavior and save/restore of file timestamps
http://svn.haxx.se/users/archive-2003-11/0157.shtml
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.
http://svn.haxx.se/users/archive-2003-11/0263.shtml
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
http://svn.haxx.se/users/archive-2003-11/0264.shtml
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
feature."
[11] ======== Postings from 2004 ========
Don't need commit-times, now-times. Needed only real create/modify times.
http://svn.haxx.se/users/archive-2004-01/0598.shtml
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?"
http://svn.haxx.se/users/archive-2004-01/0602.shtml
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."
http://svn.haxx.se/users/archive-2004-01/0642.shtml
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."
http://svn.haxx.se/users/archive-2004-01/0644.shtml
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
http://svn.haxx.se/users/archive-2004-04/0034.shtml
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
timestamp?"
http://svn.haxx.se/users/archive-2004-04/0040.shtml
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."
http://svn.haxx.se/users/archive-2004-04/0089.shtml
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?
http://svn.haxx.se/users/archive-2004-05/0209.shtml
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."
http://svn.haxx.se/users/archive-2004-05/0210.shtml
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
properties.)
http://svn.haxx.se/users/archive-2004-05/0261.shtml
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
http://svn.haxx.se/users/archive-2004-07/0312.shtml
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
http://svn.haxx.se/users/archive-2004-07/0313.shtml
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?
http://svn.haxx.se/users/archive-2004-09/0517.shtml
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
http://svn.haxx.se/users/archive-2004-09/0518.shtml
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
http://svn.haxx.se/users/archive-2004-09/0521.shtml
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
committed.
http://svn.haxx.se/users/archive-2004-09/0522.shtml
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.
Steve
Re: preserve modification date on co?
http://svn.haxx.se/users/archive-2004-09/0510.shtml
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
implementation.
Re: svn - saving time stamps of files - your posts 05/2003
http://svn.haxx.se/dev/archive-2004-10/0957.shtml
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
http://svn.haxx.se/dev/archive-2004-11/0199.shtml
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
http://subversion.tigris.org/issues/show_bug.cgi?id=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
http://svn.haxx.se/dev/archive-2004-11/0202.shtml
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
http://svn.haxx.se/dev/archive-2004-11/0203.shtml
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
http://svn.haxx.se/dev/archive-2004-11/0206.shtml
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...
http://svn.haxx.se/dev/archive-2004-11/0253.shtml
[PATCH] saving timestamps as properties
http://svn.haxx.se/dev/archive-2004-11/0411.shtml
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
http://svn.haxx.se/dev/archive-2004-11/att-0411/patch-tstamp-svn1.1.1-2.patch
* text/x-diff attachment: patch-tstamp-svn1.1.1-doc-2.patch
http://svn.haxx.se/dev/archive-2004-11/att-0411/patch-tstamp-svn1.1.1-doc-2.patch
http://svn.haxx.se/dev/archive-2004-11/0482.shtml
http://svn.haxx.se/dev/archive-2004-11/0639.shtml
[regression test failure]
http://svn.haxx.se/dev/archive-2004-11/0669.shtml
http://svn.haxx.se/dev/archive-2004-11/0674.shtml
http://svn.haxx.se/dev/archive-2004-11/0675.shtml
http://svn.haxx.se/dev/archive-2004-11/0676.shtml
http://svn.haxx.se/dev/archive-2004-11/0742.shtml
http://svn.haxx.se/dev/archive-2004-12/0967.shtml
http://svn.haxx.se/dev/archive-2004-12/0973.shtml
Export without last-commit timestamp
http://svn.haxx.se/users/archive-2004-11/1369.shtml
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.
http://svn.haxx.se/users/archive-2004-11/1382.shtml
http://svn.haxx.se/users/archive-2004-11/1385.shtml
"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
http://svn.haxx.se/users/archive-2004-12/1380.shtml
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
http://svn.haxx.se/users/archive-2005-01/1005.shtml
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
http://svn.haxx.se/users/archive-2005-01/1018.shtml
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
http://svn.haxx.se/users/archive-2005-01/1040.shtml
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
http://svn.haxx.se/users/archive-2005-01/1055.shtml
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.
http://svn.haxx.se/users/archive-2005-01/1058.shtml
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.
http://svn.haxx.se/users/archive-2005-01/1068.shtml
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.
http://svn.haxx.se/users/archive-2005-01/1212.shtml
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:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
Marius Gedminas
What I need to do to have patch for Issue 1256 applied?
http://svn.haxx.se/dev/archive-2005-02/0672.shtml
Tardif, Sebastien <STARDIF_at_anacomp.com> !!++
Date: 2005-02-18 20:41:36 CET
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
http://svn.haxx.se/dev/archive-2005-02/0674.shtml
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.
http://svn.haxx.se/dev/archive-2005-02/0684.shtml
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?
http://svn.haxx.se/users/archive-2005-03/1037.shtml
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.
http://svn.haxx.se/users/archive-2005-03/1055.shtml
http://svn.haxx.se/users/archive-2005-03/1204.shtml
http://svn.haxx.se/users/archive-2005-03/1211.shtml
http://svn.haxx.se/users/archive-2005-03/1317.shtml
http://svn.haxx.se/users/archive-2005-03/1360.shtml
http://svn.haxx.se/users/archive-2005-03/1367.shtml
"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."
http://svn.haxx.se/users/archive-2005-03/1368.shtml
SVN revert maybe should not revert timestamp with use-commit-times enabled
http://svn.haxx.se/users/archive-2005-03/1068.shtml
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)
http://svn.haxx.se/dev/archive-2005-03/0894.shtml
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.
http://svn.haxx.se/dev/archive-2005-03/0965.shtml
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
http://svn.haxx.se/dev/archive-2005-03/0998.shtml
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?
http://svn.haxx.se/dev/archive-2005-03/1004.shtml
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.
http://svn.haxx.se/dev/archive-2005-03/1011.shtml
http://svn.haxx.se/dev/archive-2005-03/1014.shtml
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
http://svn.haxx.se/dev/archive-2005-03/1006.shtml
Re: Timestamp Frustrations/ FAQ update
http://svn.haxx.se/dev/archive-2005-06/0212.shtml
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:
http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/
for the branch; see
http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2
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).
http://svn.haxx.se/users/archive-2005-06/0239.shtml
http://svn.haxx.se/users/archive-2005-06/0243.shtml
http://svn.haxx.se/users/archive-2005-06/0249.shtml
http://svn.haxx.se/users/archive-2005-06/0257.shtml
http://svn.haxx.se/users/archive-2005-06/0258.shtml
James Berry <james_at_jberry.us> !!++
Date: 2005-06-03 17:19:48 CEST
"Sounds to me like maybe you just want rsync."
http://svn.haxx.se/users/archive-2005-06/0332.shtml
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.
http://svn.haxx.se/users/archive-2005-06/0250.shtml
[uh, no]
http://svn.haxx.se/users/archive-2005-06/0253.shtml
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:
http://svn.collab.net/repos/svn/branches/meta-data-versioning/"
http://svn.haxx.se/users/archive-2005-06/0348.shtml
Phil <philipp.marek_at_bmlv.gv.at>
Date: 2005-06-05 10:12:47 CEST
"Please see
http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/
for the branch; see
http://marc.theaimsgroup.com/?l=subversion-dev&m=111459962412224&w=2
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
http://svn.haxx.se/users/archive-2005-06/0235.shtml
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
http://svn.haxx.se/dev/archive-2005-06/0997.shtml
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.
http://svn.haxx.se/dev/archive-2005-06/0999.shtml
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?"
http://svn.haxx.se/dev/archive-2005-06/1005.shtml
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...
http://svn.haxx.se/dev/archive-2005-06/1009.shtml
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.
http://svn.haxx.se/dev/archive-2005-06/1027.shtml
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"
http://svn.haxx.se/dev/archive-2005-06/1018.shtml
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
http://svn.haxx.se/dev/archive-2005-07/0270.shtml
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)?
http://svn.haxx.se/users/archive-2005-07/0475.shtml
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
http://svn.haxx.se/users/archive-2005-07/0593.shtml
Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2005-07-11 09:18:09 CEST
"Please see issue 1256
http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
and the thread...
http://svn.haxx.se/users/archive-2005-07/0604.shtml
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.
http://svn.haxx.se/users/archive-2005-07/0617.shtml
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.
http://svn.haxx.se/users/archive-2005-07/0618.shtml
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."
http://svn.haxx.se/users/archive-2005-07/0619.shtml
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."
http://svn.haxx.se/users/archive-2005-07/0635.shtml
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).
http://svn.haxx.se/users/archive-2005-07/0643.shtml
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?
http://svn.haxx.se/users/archive-2005-07/0647.shtml
Karl <kfogel_at_collab.net>
Date: 2005-07-11 20:08:23 CEST
"Sometimes we decide the benefit isn't worth the cost."
http://svn.haxx.se/users/archive-2005-07/0677.shtml
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?
http://svn.haxx.se/users/archive-2005-07/1380.shtml
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
http://svn.haxx.se/users/archive-2005-08/0594.shtml
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."
http://svn.haxx.se/users/archive-2005-08/0649.shtml
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
http://svn.haxx.se/dev/archive-2005-08/0597.shtml
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
http://svn.haxx.se/dev/archive-2005-08/0601.shtml
http://svn.haxx.se/dev/archive-2005-08/0610.shtml
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!!!
http://svn.haxx.se/dev/archive-2005-08/0668.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0679.shtml
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?
Svante
http://svn.haxx.se/dev/archive-2005-08/0732.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0757.shtml
Rob Anderson <rob.anderson_at_juicegames.com> !!++
Date: 2005-08-19 10:46:09 CEST
"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? ;( Rob.
http://svn.haxx.se/dev/archive-2005-08/0764.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0789.shtml
Philip Martin <philip_at_codematters.co.uk>
Date: 2005-08-19 17:28:18 CEST
[questions, comments]
http://svn.haxx.se/dev/archive-2005-08/0799.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0804.shtml
Philip Martin <philip_at_codematters.co.uk>
Date: 2005-08-19 18:38:25 CEST
[questions, comments]
http://svn.haxx.se/dev/archive-2005-08/0809.shtml
http://svn.haxx.se/dev/archive-2005-08/0810.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0816.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0819.shtml
http://svn.haxx.se/dev/archive-2005-08/0824.shtml
http://svn.haxx.se/dev/archive-2005-08/0829.shtml
http://svn.haxx.se/dev/archive-2005-08/0830.shtml
Joshua Varner <jlvarner_at_gmail.com>
Date: 2005-08-19 23:16:58 CEST
[questions, comments]
http://svn.haxx.se/dev/archive-2005-08/0831.shtml
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
again.
http://svn.haxx.se/dev/archive-2005-08/0832.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0835.shtml
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
implementation.
http://svn.haxx.se/dev/archive-2005-08/0836.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0908.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0921.shtml
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...
http://svn.haxx.se/dev/archive-2005-08/0936.shtml
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
http://svn.haxx.se/dev/archive-2005-08/0947.shtml
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.
http://svn.haxx.se/dev/archive-2005-08/0952.shtml
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?
http://svn.haxx.se/users/archive-2005-09/0347.shtml
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?"
http://svn.haxx.se/users/archive-2005-09/0349.shtml
http://svn.haxx.se/users/archive-2005-09/0353.shtml
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
http://svn.haxx.se/tsvnusers/archive-2005-11/0009.shtml
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
http://svn.haxx.se/users/archive-2005-11/0687.shtml
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?"
http://svn.haxx.se/users/archive-2005-11/0772.shtml
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
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
for another example. Graeme.
Way to update timestamp to committed timestamp?
http://svn.haxx.se/users/archive-2005-11/0800.shtml
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."
http://svn.haxx.se/users/archive-2005-11/0805.shtml
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?
http://svn.haxx.se/users/archive-2005-11/0822.shtml
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
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
I would argue for this also being another bug / deficiency.
Graeme
[DESIGN] mtime versioning - was: Getting Bug 1256 fixed
http://svn.haxx.se/dev/archive-2005-11/1212.shtml
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).
http://svn.haxx.se/dev/archive-2005-11/1383.shtml
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...
http://svn.haxx.se/dev/archive-2005-11/1384.shtml
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
http://svn.haxx.se/dev/archive-2005-11/1389.shtml
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.
http://svn.haxx.se/dev/archive-2005-11/1410.shtml
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?
http://svn.haxx.se/dev/archive-2005-11/1411.shtml
[details]
http://svn.haxx.se/dev/archive-2005-11/1412.shtml
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.
http://svn.haxx.se/dev/archive-2005-11/1413.shtml
http://svn.haxx.se/dev/archive-2005-11/1440.shtml
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.
http://svn.haxx.se/dev/archive-2005-11/1444.shtml
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:
Configuration:
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.
Requirements:
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
http://svn.haxx.se/dev/archive-2005-11/1450.shtml
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
http://svn.haxx.se/tsvnusers/archive-2005-11/0286.shtml
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
http://svn.haxx.se/tsvnusers/archive-2005-12/0014.shtml
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:
http://svnbook.red-bean.com/nightly/en/svn.advanced.html#svn.advanced.confarea.opts.config
Have a look at "use-commit-times". Stefan.
RE: FW: date time stamp
http://svn.haxx.se/users/archive-2005-12/0138.shtml
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.]
Revert
http://svn.haxx.se/tsvnusers/archive-2005-12/0097.shtml
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."
http://svn.haxx.se/tsvnusers/archive-2005-12/0098.shtml
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
http://svn.haxx.se/users/archive-2006-01/0047.shtml
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
http://svn.haxx.se/users/archive-2006-01/0049.shtml
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
http://svn.haxx.se/dev/archive-2006-01/0328.shtml
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."
http://svn.haxx.se/dev/archive-2006-01/0330.shtml
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."
http://svn.haxx.se/dev/archive-2006-01/0333.shtml
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:
http://svn.haxx.se/users/archive-2005-11/1101.shtml
File timestamps
http://svn.haxx.se/users/archive-2006-01/0379.shtml
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
choices.
Re: Effects of importing over 18000 items into repository as one
commit transaction
http://svn.haxx.se/dev/archive-2006-01/0316.shtml
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)
http://svn.haxx.se/users/archive-2006-03/0311.shtml
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:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=257080
[...] 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
http://svn.haxx.se/users/archive-2006-03/0320.shtml
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:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
README.TXT?view=markup&rev=14236
RE: Preserve commit times (issue #1256)
http://svn.haxx.se/users/archive-2006-03/0322.shtml
Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
Date: 2006-03-08 11:03:23 CET
"Bug updated with link to design discussion:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
I see that this is slipping again!"
http://svn.haxx.se/users/archive-2006-03/0940.shtml
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
Progammer.
Timestamp help FPGA HDL
http://svn.haxx.se/users/archive-2006-07/0207.shtml
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...
http://svn.haxx.se/users/archive-2006-07/0209.shtml
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.
http://svn.haxx.se/users/archive-2006-07/0226.shtml
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:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
Keeping last-modified dates
http://svn.haxx.se/users/archive-2006-08/1331.shtml
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"
http://svn.haxx.se/users/archive-2006-08/1340.shtml
[why? "tell us your use-case please!"]
http://svn.haxx.se/users/archive-2006-08/1366.shtml
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.
Andrew"
http://svn.haxx.se/users/archive-2006-08/1370.shtml
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...."
http://svn.haxx.se/users/archive-2006-08/1394.shtml
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
colleagues..."
http://svn.haxx.se/users/archive-2006-08/1395.shtml
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..."
http://svn.haxx.se/users/archive-2006-08/1401.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1402.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1403.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1439.shtml
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!
http://svn.haxx.se/users/archive-2006-08/1418.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1404.shtml
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
distribution.
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
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...
http://svn.haxx.se/users/archive-2006-08/1414.shtml
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
http://svn.haxx.se/users/archive-2006-08/1419.shtml
Greg Thomas <thomasgd_at_omc.bt.co.uk>
Date: 2006-08-29 16:01:12 CEST
[on 'make']
http://svn.haxx.se/users/archive-2006-08/1420.shtml
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... [...]
http://svn.haxx.se/users/archive-2006-08/1425.shtml
Andrew Webb <andrew.microi_at_gmail.com>
Date: 2006-08-29 16:38:22 CEST
[more on 'make']
http://svn.haxx.se/users/archive-2006-08/1448.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1470.shtml
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
convenience."
http://svn.haxx.se/users/archive-2006-08/1472.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1486.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1488.shtml
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 *]
http://svn.haxx.se/users/archive-2006-08/1474.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1477.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1509.shtml
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
http://svn.haxx.se/users/archive-2006-08/1515.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1455.shtml
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..."
http://svn.haxx.se/users/archive-2006-08/1468.shtml
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
http://svn.haxx.se/users/archive-2006-08/1476.shtml
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
information."
http://svn.haxx.se/users/archive-2006-08/1478.shtml
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 ;)."
http://svn.haxx.se/users/archive-2006-08/1479.shtml
http://svn.haxx.se/users/archive-2006-08/1454.shtml
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?"
http://svn.haxx.se/users/archive-2006-08/1428.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1489.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1490.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1491.shtml
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
http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
and then incorporate it into the trunk!"
http://svn.haxx.se/users/archive-2006-08/1492.shtml
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 "
http://svn.haxx.se/users/archive-2006-08/1497.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
http://svn.haxx.se/users/archive-2006-08/1495.shtml
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
http://svn.haxx.se/users/archive-2006-08/1501.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1512.shtml
[confusion]
http://svn.haxx.se/users/archive-2006-08/1513.shtml
http://svn.haxx.se/users/archive-2006-08/1516.shtml
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"
http://svn.haxx.se/users/archive-2006-08/1507.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1519.shtml
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
http://svn.haxx.se/users/archive-2006-08/1405.shtml
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."
http://svn.haxx.se/users/archive-2006-08/1417.shtml
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.
http://svn.haxx.se/users/archive-2006-08/1487.shtml
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
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
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
http://svn.haxx.se/users/archive-2006-09/0365.shtml
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
http://svn.haxx.se/users/archive-2006-09/0368.shtml
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.
http://svn.haxx.se/users/archive-2006-09/0374.shtml
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:
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
[PROPOSAL] Versioning mtime
http://svn.haxx.se/dev/archive-2006-09/0492.shtml
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.
http://svn.haxx.se/dev/archive-2006-09/0879.shtml
http://svn.haxx.se/dev/archive-2006-09/0933.shtml
http://svn.haxx.se/dev/archive-2006-09/0973.shtml
http://svn.haxx.se/dev/archive-2006-09/0974.shtml
Tortoise svn files date/time
http://svn.haxx.se/tsvnusers/archive-2006-09/0309.shtml
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
http://svn.haxx.se/tsvnusers/archive-2006-09/0318.shtml
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
http://svn.haxx.se/dev/archive-2006-10/0048.shtml
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.
http://svn.haxx.se/users/archive-2005-11/1101.shtml
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***]
http://svn.haxx.se/dev/archive-2006-10/0051.shtml
Re: [PROPOSAL] Versioning mtime [ *** Design work *** ]
http://svn.haxx.se/dev/archive-2006-10/0193.shtml
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'.
http://svn.haxx.se/dev/archive-2006-10/0195.shtml
Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2006-10-09 07:01:28 CEST
[comments]
http://svn.haxx.se/dev/archive-2006-10/0742.shtml
Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-10-26 23:01:07 CEST
[comments]
http://svn.haxx.se/dev/archive-2006-10/0761.shtml
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
http://svn.haxx.se/users/archive-2006-10/1319.shtml
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?"
http://svn.haxx.se/users/archive-2006-10/1324.shtml
Mark <mark_at_mitsein.net>
Date: 2006-10-27 00:11:38 CEST
http://svn.haxx.se/users/archive-2006-10/1329.shtml
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:
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
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:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
http://svn.haxx.se/users/archive-2006-10/1345.shtml
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
http://svn.haxx.se/users/archive-2006-11/0040.shtml
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
http://svn.haxx.se/users/archive-2006-11/0057.shtml
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:
http://svn.haxx.se/dev/archive-2006-09/0492.shtml
http://svn.haxx.se/dev/archive-2006-10/0193.shtml
(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.
http://svn.haxx.se/users/archive-2006-11/0059.shtml
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
http://svn.haxx.se/users/archive-2007-01/0003.shtml
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
http://svn.haxx.se/users/archive-2007-01/0006.shtml
http://svn.haxx.se/users/archive-2007-01/0012.shtml
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!
http://svn.haxx.se/users/archive-2007-01/0019.shtml
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
http://svn.haxx.se/users/archive-2007-01/0032.shtml
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
http://svn.haxx.se/users/archive-2007-01/0141.shtml
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
http://svn.haxx.se/users/archive-2007-01/0142.shtml
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?
http://svn.haxx.se/users/archive-2007-01/0718.shtml
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."
http://svn.haxx.se/users/archive-2007-01/0721.shtml
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?
http://svn.haxx.se/tsvnusers/archive-2007-02/0156.shtml
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?
http://svn.haxx.se/users/archive-2007-02/1185.shtml
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
(http://subversion.tigris.org/issues/show_bug.cgi?id=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.
http://svn.haxx.se/users/archive-2007-02/1186.shtml
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.
Oliver.
http://svn.haxx.se/users/archive-2007-02/1213.shtml
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?"
http://svn.haxx.se/users/archive-2007-02/1244.shtml
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.
http://svn.haxx.se/users/archive-2007-02/1266.shtml
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.
http://svn.haxx.se/users/archive-2007-02/1311.shtml
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
anyway.
http://svn.haxx.se/users/archive-2007-02/1320.shtml
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
http://svn.haxx.se/dev/archive-2006-09/0492.shtml
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
coordinate)
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.
http://svn.haxx.se/users/archive-2007-02/1313.shtml
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!"
http://svn.haxx.se/users/archive-2007-02/1216.shtml
http://svn.haxx.se/users/archive-2007-02/1234.shtml
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."
http://svn.haxx.se/users/archive-2007-02/1235.shtml
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."
http://svn.haxx.se/users/archive-2007-02/1237.shtml
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.
http://svn.haxx.se/users/archive-2007-02/1247.shtml
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
times."
http://svn.haxx.se/users/archive-2007-02/1236.shtml
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.
http://svn.haxx.se/users/archive-2007-02/1273.shtml
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..."
http://svn.haxx.se/users/archive-2007-02/1309.shtml
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..."
http://svn.haxx.se/users/archive-2007-02/1312.shtml
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
http://svn.haxx.se/tsvnusers/archive-2007-03/0001.shtml
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
http://svn.haxx.se/tsvnusers/archive-2007-03/0002.shtml
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).
http://svn.haxx.se/tsvnusers/archive-2007-03/0003.shtml
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
http://blog.surfulater.com/2007/02/28/get-up-and-running-with-tortoisesvn-and-subversion-in-15-minutes/
I probably would have stayed with my previous VCS.
http://svn.haxx.se/tsvnusers/archive-2007-03/0005.shtml
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
http://svn.haxx.se/tsvnusers/archive-2007-03/0006.shtml
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.
http://svn.haxx.se/tsvnusers/archive-2007-03/0015.shtml
<steven.davison_at_juno.com>
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?
http://svn.haxx.se/users/archive-2007-03/0013.shtml
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.
http://svn.haxx.se/users/archive-2007-03/0015.shtml
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.
http://svn.haxx.se/users/archive-2007-03/0017.shtml
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..."
http://svn.haxx.se/users/archive-2007-03/0109.shtml
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
information.
http://svn.haxx.se/users/archive-2007-03/0115.shtml
Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-03 07:57:10 CET
http://svn.haxx.se/users/archive-2007-03/0123.shtml
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... :-)
http://svn.haxx.se/users/archive-2007-03/0201.shtml
Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-06 11:01:04 CET
"You can find the bug at:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
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).
http://svn.haxx.se/users/archive-2007-03/0251.shtml
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
http://svn.haxx.se/users/archive-2007-03/1291.shtml
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
http://svn.haxx.se/users/archive-2007-03/0016.shtml
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).
http://svn.haxx.se/users/archive-2007-03/1294.shtml
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."
http://svn.haxx.se/users/archive-2007-03/1342.shtml
svn import/commit doesn't preserve file timestamp
http://svn.haxx.se/users/archive-2007-05/0475.shtml
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
deficiency."
http://svn.haxx.se/users/archive-2007-05/0484.shtml
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.
http://svn.haxx.se/users/archive-2007-05/0564.shtml
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
http://svn.haxx.se/users/archive-2006-10/1345.shtml
But it's intended only for the initial import. During
normal work I'm using the commit time."
Re: retroactive mtime versioning
http://svn.haxx.se/users/archive-2007-05/1034.shtml
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.
http://svn.haxx.se/users/archive-2007-05/1036.shtml
Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-05-30 00:16:31 CEST
"It has been done before: the text-time branch:
http://svn.collab.net/viewvc/svn/branches/meta-data-versioning/
Unfortunately that code hasn't been touched in two years.
Subversion, binary files, hex editors and file modification time
http://svn.haxx.se/dev/archive-2007-06/0315.shtml
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."
http://svn.haxx.se/dev/archive-2007-06/0318.shtml
"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)."
http://svn.haxx.se/dev/archive-2007-06/0324.shtml
http://svn.haxx.se/dev/archive-2007-06/0327.shtml
"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."
http://svn.haxx.se/dev/archive-2007-06/0358.shtml
http://svn.haxx.se/dev/archive-2007-06/0488.shtml
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/
translated/archived/obfuscated/proofread/
stripped/paraphrased from a file whose mtime was...")
use-commit-times
http://svn.haxx.se/users/archive-2007-07/0318.shtml
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?
http://svn.haxx.se/users/archive-2007-09/0155.shtml
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
http://svn.haxx.se/users/archive-2007-09/0157.shtml
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
feature.
maintaining file modified dates during svn import?
http://svn.haxx.se/users/archive-2007-09/0712.shtml
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
http://svn.haxx.se/users/archive-2007-09/0717.shtml
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
http://svn.haxx.se/users/archive-2007-10/0409.shtml
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?
http://svn.haxx.se/users/archive-2007-10/0415.shtml
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.
http://svn.haxx.se/users/archive-2007-10/0416.shtml
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
(http://subversion.tigris.org/issues/show_bug.cgi?id=1256)
has been raised to get this feature added.
Subversion, date/time question on initial import or add
http://svn.haxx.se/users/archive-2007-11/0361.shtml
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
http://svn.haxx.se/users/archive-2007-11/0376.shtml
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
script.
http://svn.haxx.se/users/archive-2007-11/0383.shtml
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
http://svn.haxx.se/users/archive-2007-09/0730.shtml
Lorenz
[15] ======== Postings from 2008 ========
Any progress toward "preserve timestamps"
http://svn.haxx.se/users/archive-2008-01/0661.shtml
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
http://svn.haxx.se/users/archive-2008-01/0665.shtml
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
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
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
http://svn.haxx.se/users/archive-2008-03/0310.shtml
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
http://svn.haxx.se/users/archive-2008-03/0319.shtml
Paul Koning <Paul_Koning_at_dell.com>
Date: Mon, 10 Mar 2008 12:20:30 -0400
"Subversion doesn't preserve timestamps. - paul"
http://svn.haxx.se/users/archive-2008-03/0352.shtml
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:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
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
http://svn.haxx.se/users/archive-2008-03/0384.shtml
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