[jira] [Commented] (SVN-1256) Ability to preserve last modification time (mtime) of files under version control

    [ 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)