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

Re: Once more: Subversion and file modification time (mtime)

From: Robin Cover <robincover_at_gmail.com>
Date: Thu, 13 Mar 2008 10:36:35 -0500

On Thu, Mar 13, 2008 at 9:48 AM, Reedick, Andrew <jr9445_at_att.com> wrote:
>
>
> > -----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.

Thank you for prompting this clarification: I intended to say that I
support a solution (user option) which accommodates the needs of
those who do and don't want mtime-based operations.

I agree that code-centric version control systems must cater first
of all to coders and their code-processing application software, so
indeed, breaking 'make' trumps other use cases.

Others (more qualified to write the detailed technical requirements
and implementation proposals) have provided some basis for discussion
and further action:

*Erik Huelsmann (2006-09-16)
*http://svn.haxx.se/dev/archive-2006-09/0492.shtml
 - http://svn.haxx.se/dev/archive-2005-08/0764.shtml
 - http://svn.haxx.se/dev/archive-2005-11/1212.shtml

Best wishes,

Robin

  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. Version control systems are
> code-centric which implies build-centric so breaking make seems to trump
> unbreaking other use cases.
>
> 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.
>
>
>
>
> [1] Example:
> Foo.c r99 has a timestamp of Monday
> Foo.c r100 has a timestamp of Tuesday
> Build r100 on Wednesday,
> so foo.o has a timestamp of Wednesday.
> Roll Foo.c back to r99 (timestamp of Monday)
> Rebuild. Make does nothing since:
> Foo.c - timestamp of Monday
> Foo.o - timestamp of Wednesday
> Which leaves you with a Foo.o that was built with r100 instead
> of r99
> ClearCase's omake would see that Foo.o was built with r100 and then
> rebuild it using r99.
>
>
>
> *****
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
>
>
>

-- 
Robin Cover
WWW:  http://xml.coverpages.org
Tel: +1 (972) 296-1783
---------------------------------------------------------------------
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:37:12 CET

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.