At 02:58 PM 6/8/2009, Ryan Schmidt wrote:
>>>>>
> > Incidentally, when I blew away those directories and updated them in
> > my sandbox, it totally screws up the file dating, i.e. it dates all
> > the files with the current date and time.
>
>This is considered a feature, not a bug. When you check out or
>update, modified and added files get their modification time set to
>"now". This is what many software developers want, because it allows
>the "make" program, which many software developers use, to know which
>source files need to be recompiled.
>
>If this is not what you want, perhaps because you don't use "make",
>the other option available to you is to have added and modified files
>get their modification time set to the commit time. You get this
>behavior by setting "use-commit-times = yes" in your client's
>Subversion config file.
<<<<<
We're using Subversion to version a lot of stuff besides source
files, e.g. policy-and-procedure documents, SRS, SDD, various and
assorted project plans, etc.
I suppose updating to time-of-checkout makes sense (sort of) for
source files, but not for other stuff. Unfortunately TortoiseSVN
doesn't seem to support "pro-choice" transparently... it seems you
have to configure it to check out with time-of-checkout for those
files for which you want that, and then reconfigure for
time-of-commit otherwise.
>>>>>
>Another option some people want is to have Subversion use the actual
>modification time of the file, as distinct from the commit time.
<<<<<
Yes, that is my runaway #1 preference, leaves all other alternatives
in the dust. I have had clients (and one of my partners, back when I
was a partner in an engineering company) flat-out refuse to use
Subversion, citing that as a big reason... of course my partner also
cited "concurrent versioning" as a big reason he refused to use it,
so you can take that for what it's worth. :-\
>>>>>
>This is not possible at present because Subversion does not store
>modification times. The request to add this feature is filed here:
>
>http://subversion.tigris.org/issues/show_bug.cgi?id=1256
<<<<<
Yes, I read through all of that one, with entries dating from April
of '03 to March of '09, with a reference in one of the April '03
entries to discussions on the topic that had taken place "over the
years" previous, implying that the issue had been an issue for some
number of years previous to '03.
Of course, Subversion has only been around since, what, 2000 or
so? So it couldn't have been too many "years" previous to '03...
although presumably this was also an issue with CVS (I did use CVS
back in the '90's and seem to vaguely recall people complaining about
it even then).
Many of the notes in that bug report say things like "pushed to
1.x-consider" where "x" gets incremented each time... currently it's
at 1.8-consider.
Interesting to note that I didn't see a single entry from anybody who
did NOT want to be able to store mod times, and lots and lots from
those who consider it virtually vital to at least have that as an option.
Not that that would stop me from, y'know, USING Subversion or anything... :-)
(It's really a fantastic piece of software despite such a serious problem...)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360442
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-08 22:04:56 CEST