This feature has been discussed over and over through the years; if
you search the dev@ archives, you can read the debates. The opinion
of the dev team is that this is not a useful feature in general;
while it might help a very small minority of users that wish to track
original timestamps, it would create more trouble and complexity for
the majority, and be hard to maintain. So the lack of this feature is
a deliberate decision, not an accidental oversight.
The arguments against the feature have basically been:
* When no version control is used, then it's clear file timestamps are
critical. They're the only indication of a file's "version". But
once the files are placed into version control, what's the point of
tracking the original datestamps? Version control is now providing
much more detailed tracking of versions and dates. It's solving the
problem is a much more thorough way.
* Version control is typically used for code. Having timestamps
touched by 'svn update' solves the 90% use-case of causing programs
like 'make' to rebuild exactly what has changed. This is a useful and
important default behavior.
* For all other cases, the 'use-commit-times=true' option causes
timestamps to reflect repository mod-times, rather than 'svn up'
mod-times, thus providing the same sort of simulated
versioning-via-timestamp for files being exported to people without
subversion.
* If you want to be even friendlier to people without subversion, you
can put $LastChangedDate$ or $Revision$ keywords directly into the
files to be expanded.
If none of these features satisifes your use-case, I'm curious to hear
exactly what you're trying to accomplish, and why these solutions
don't work for you.
2008/7/10 郭煜 <guoy_at_dscomm.com.cn>:
> Dear Mr. Unterberg,
>
>
> Yes , I see that subversion support good functions but based on lost
> file modify date. Is it?
>
> I like subversion client very much. But as an end user, we can't select
> a version control system which can't save file modify date. Because this is
> very important for our team-work in software developement progress. It's so
> sorry.
>
> I think that you can get better idea yourself to shot the problem
> later. Perhaps other version control system could be your referrence. If
> this problem is ok, contract me as soon as you can please. We'll select
> subversion as our version control system.
>
> Thanks & Best Regards,
> Yvon Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
> Addr: 上海市平江路15号（zip:200050）
> Tel(O): 86-21-64031580 x 2512
> Tel(MB): 13916313249
>
> ----- Original Message -----
> From: "Norbert Unterberg" <nunterberg_at_gmail.com>
> To: "郭煜" <guoy_at_dscomm.com.cn>
> Cc: <users_at_subversion.tigris.org>; <dev_at_subversion.tigris.org>
> Sent: Friday, July 11, 2008 5:06 AM
> Subject: Re: Subversion Problem - How to save file modify time?
>> 2008/7/10 郭煜 <guoy_at_dscomm.com.cn>:
>> > Dear Invendor,
>> >
>> > This is a software company in china. I'm an engineer at
>> > develope-management department.
>> >
>> > We used other version control system as perforce or starteam before.
>> > Now we are trying subversion.
>> >
>> > During trying subversion, we find that file modify time could not be
>> > saved into subversion and get from subversion.
>> >
>> > Is it a design problem or deploy problem ? I hope it's a deploy
>> > problem. How to shot it, if a deploy problem.
>> >
>>
>> There is a configuration option "use-commit-times" which you can find
>> in the documentation, It does not preserve the real file modify time
>> but the commit time which might be good enough.
>> However, for software development, the default behaviour (file time is
>> the time of last update or checkout) usually works best.
>>
>> The problem with preserving file modify time is that it is very hard
>> to do right. What is the correct modify time if two people change the
>> same file and then they commit/update/merge the data? What to do when
>> merging a branch? IF SVN modifies the file contents during a commit
>> (see svn:keyword property) does that count as a file modification or
>> not?
>>
>> Norbert
>>
Received on 2008-07-11 04:43:53 CEST