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

Re: Keeping last-modified dates

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-08-29 22:25:30 CEST

On 8/29/2006 2:15 PM, Steve Fairhead wrote:
> Erik Huelsmann said:
>> This is fairly bogus. So Alice has edited a file, thrown it away, and
>> reverted to an earlier version. With or without a VCS, this is (as I
>> said earlier in another post) the sort of situation that breaks makefiles
> anyway.
>> I'd do a make clean.
> Well, it may break other VCS with makefiles, but this scenario works under
> Subversion, so, although make clean is a very good idea (always), there is
> not stricktly a need to with svn...
> <<
> Yes, I realise that svn's current behaviour would favour this one scenario.
> However, I can offer plenty of counter arguments. Consider a project where
> some data files are built by some utilities, also within the project (the
> ./configure example has been used before). Whether or not the makefile
> figures it needs to rebuild the data files is currently a roll of the dice.
> In fact, the ability of the makefile to infer *any* kind of status of the
> component parts of some entity is entirely nuked by svn. As far as I can
> see, you have no choice *but* to do a make clean anyway.
> Like others have said, I'm fairly used to gaining a quick idea of the state
> of play of the project by sorting by date. Some files are current; some may
> not have changed in years. I'm currently looking at a source file folder in
> which some font files were built back in the 80s. The last-modified-date
> timestamp is a useful piece of data which svn simply discards. As I said
> earlier, this rules out svn for production use for me/us. Seems a shame. So
> near, yet so b0rked.

I would guess that it wouldn't be impossible to write wrapper scripts
for svn that put the last mod date into a property just before a commit,
and then modified the date based on that property just after a checkout
or update. Tricky decisions would be what to do if an update resulted
in a merge (presumably keep the merge time as last mod time), and
recognizing cases where someone checked something in without using your
script (so you'd need to fall back to the commit time).

Duncan Murdoch

> Steve
> http://www.sfdesign.co.uk
> http://www.fivetrees.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 22:31:52 2006

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.