[
https://issues.apache.org/jira/browse/SVN-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846859#comment-16846859
]
Joe Chlimoun commented on SVN-1256:
-----------------------------------
Bumping this to affirm that this is miscategorized as a new feature, when it is
a bug. I call it a bug because it fails the first rule of version control
systems: be able to export/restore a file exactly as it was when imported.
There is no good reason to abandon source metadata, including ctime and mtime.
Honestly, I've used subversion for years without noticing or caring about this
issue, as I'm sure most subversion users have. And I do understand the
complexity of this, both in terms of the concept of subversion version
controlling on a revision-basis instead of a file-basis, and in terms of having
to deal with how various file systems handle the storage of metadata. I get it.
It's a pain in the ass, and it will cause compatibilty issues when someone uses
some arcane file system that isn't anticipated and supported. But this issue
has become a real headache in my new subversion deployment where I have a
program that absolutely needs dates to be consistent with what it received
before. When suddenly dates are updated to the checkout date or commit date,
it's a full stop. Yes, this is a poor design, but one poor design doesn't
excuse another. I should be able to restore a version-controlled file to
exactly its previous state, data and metadata, as other version control systems
are able to do. Our previous version control system handled this fine, I know
others do as well.
Someone mentioned earlier - years ago - that what's preventing this from moving
forward is a lack of a functional spec. I don't buy that for a second, as this
should be fairly straightforward. This can be completely implemented through
file properties on an automated basis, where the properties are created on an
add, restored on checkout/export, and updated on a commit/merge to the most
recent mdate. It doesn't need to be more complicated than that, and virtually
all file systems support cdate and mdate... support for the most popular file
systems can be prioritized.
At the very least, this behavior should be configurable (similar to the
use-commit-time config parameter... "use-original-time"), but I really can't
imagine a scenario where someone wouldn't want the original timestamps. I get
having a choice between two arbitrary times - commit time vs now/checkout time
- but if original time is an option, the other two really seem pointless, aside
perhaps for an unsupported filesystem.
> Ability to preserve last modification time (mtime) of files under version
> control
> ---------------------------------------------------------------------------------
>
> Key: SVN-1256
> URL: https://issues.apache.org/jira/browse/SVN-1256
> Project: Subversion
> Issue Type: New Feature
> Affects Versions: all
> Reporter: Subversion Importer
> Priority: Major
> Labels: api, patch
> Fix For: 1.10-consider
>
> Attachments: 1_text-time.patch
>
>
> {noformat:nopanel=true}
> 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.
> {noformat}
> Original issue reported by *flying*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
