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

Re: Subversion Problem - How to save file modify time?

From: 郭煜 <guoy_at_dscomm.com.cn>
Date: Fri, 11 Jul 2008 14:02:00 +0800

Dear Mr. Collins-Sussman,

    We used other version control system before. If using subversion was sured, we should move all files form old version control system to subversion. These files include source files and destination files and even other many invendors' source files and destination files. But, subversion will lost their modify time all. Oh... Some of our files maybe fifteen years old. A lot of our coding engineers are new. Our coding managers feels difficulty to manage the great source and tech-support the destination file without file modify time.

    Of course I think subversion developement team is the most specially on version control system. Also of course the coding habit is belong to coding engineers and coding managers. So we have to support the habit belong to them.

    It's so sorry. But we wish that this problem will be shot soon. Says again, I like subversion client very much truely.

    By the way, why could not you save the commit time to file create time and save the the last changed time to file modify time? Usually, in operation system, file create time is not really and not very useful. Why don't you use it?

Best Regards,
Guo Yu , 郭煜 / 上海迪爱斯通讯设备公司 开发一部
Addr: 上海市平江路15号(zip:200050)
Tel(O): 86-21-64031580 x 2512
Tel(MB): 13916313249

----- Original Message -----
From: "Ben Collins-Sussman" <sussman_at_red-bean.com>
To: "郭煜" <guoy_at_dscomm.com.cn>
Cc: "Norbert Unterberg" <nunterberg_at_gmail.com>; <users_at_subversion.tigris.org>; <dev_at_subversion.tigris.org>
Sent: Friday, July 11, 2008 10:43 AM
Subject: Re: Subversion Problem - How to save file modify time?

> 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 17:19:37 CEST

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

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