> -----Original Message-----
> From: Reedick, Andrew [mailto:jr9445_at_ATT.COM]
> Sent: 13 March 2008 14:48
> To: Robin Cover; Subversion Users List
> Subject: RE: Once more: Subversion and file modification time (mtime)
>
>
>
> > -----Original Message-----
> > From: Robin Cover [mailto:robincover_at_gmail.com]
> > Sent: Thursday, March 13, 2008 3:53 AM
> > To: Subversion Users List
> > Subject: Once more: Subversion and file modification time (mtime)
> >
> > [1] Introduction
> >
> > This communication raises once again the question of Subversion
> > (not) storing/recording file mtime values in an SVN repository, and
> > (thus not) making last-modified date/time values available to other
> > SVN operations, as required by predictable classes of end users and
> > their documented use cases.
> >
> > The goal here is to provide yet one more use case, and to
> seek input
> > from the core Subversion developer team [1n] about
> realistic prospects
> > for fixing this problem -- now documented in several
> hundreds of user
> > email messages since 2002. No FAQ or wishful thinking is going to
> > make this problem disappear, as far as I can see.
>
>
> You might get more traction if you can propose a
> solution or compromise that works for both sides. For
> example, since timestamps and versioning can really confuse
> make[1], ClearCase comes with a special version of make
> (called omake) that checks if the version changed instead of
> relying solely on timestamps.
The request has always been a compromise that works for all sides! There
has never been any requests to break, change or alter the existing
functionality in any way whatsoever. All that has ever been
proposed/wanted/requested is to have subversion supply the ability to
give the user the option to checkout, update, revert their files with
either the current time, last commit time or the last modified time.
Any suggestion that the several design proposals would break this
existing behaviour of subversion is completely wrong.
> Version control systems are
> code-centric which implies build-centric so breaking make
> seems to trump unbreaking other use cases.
>
Possibly, for the use cases that you have come across... There are many
other valid examples of non 'code-centric' usage, that are covered in
detail in Robin's email.
> Maybe 'svn co' would preserve the timestamp, but update
> and revert (or any command that modifies an existing
> workspace) would use current time? Update and revert would
> have a switch to allow for preserving the original timestamp.
>
If you consult the design proposals referenced in Robin's post, you will
see that all commands would have the option to use modification times,
with the client config option to set this as the default behaviour
(Before you reply, I will add, again, that the default (out of the box)
behaviour will remain as it currently is, which is to use the current
time).
I hope that this time, the issue is discussed with reasoned and rational
arguments for and against. At this point in time, I believe that there
are no (sensible) arguments as to why this should not be done and the
only problem is the availability of the overworked subversion developers
and, quite rightly, they chose to implement features that interest them,
I believe that most of them are not actually paid to develop this
software and they have done a fantastic job!
And finally - Robin, thank you for summarising this long running (in
both time and quantity) issue, hopefully we can get the interest of
someone who is willing and able to devote some of their precious time to
look at this!
Graeme
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-13 16:48:56 CET