Re: MTime resurrected

So I finally got around to updating the MTime Preservation page: http://wiki.apache.org/subversion/MtimePreservation I ended up integrating all of your suggestions, and I think I answered all the questions. The biggest changes are: * Removed the 'svn:use-text-times' property. The presence of

Re: MTime resurrected

On 01/03/2012 7:04 AM, Julian Foad wrote: Hi Rick. I see Philip Martin has added some comments in-line. I have now added comments too, as Wiki comment sections which are displayed when you click on the "Comments" buttion at the top of the page. - Julian Thanks; I'll try to find time this we

Re: MTime resurrected

Rick Yorgason wrote: >>>     >> >> Has anybody had the time to read this yet? > > Sorry Rick, I still haven't. Hi Rick. I see Philip Martin has added some comments in-line. I have now added comments too, as Wiki comment sections which ar

Re: MTime resurrected

Rick Yorgason wrote: > On 2012-02-21 4:29 AM, Julian Foad wrote: >> Rick, thanks for that!  I haven't read it yet but I've put it up > at: >> >>     > > Has anybody had the time to read this yet? Sorry Rick, I still haven't. - Julian

Re: MTime resurrected

On 2012-02-21 4:29 AM, Julian Foad wrote: Rick, thanks for that! I haven't read it yet but I've put it up at: Has anybody had the time to read this yet? -Rick-

Re: MTime resurrected

Thanks Julian, my username is RickYorgason. Cheers, -Rick- On 2012-02-21 4:29 AM, Julian Foad wrote: Rick Yorgason wrote: Alright, after the discussion on Friday I feel like I've got a better handle on the subject, so I went ahead and tried to document the intended behaviour. I noticed tha

Re: MTime resurrected

Rick Yorgason wrote: > Alright, after the discussion on Friday I feel like I've got a > better handle on the subject, so I went ahead and tried to > document the intended behaviour. > > I noticed that you seem to be moving toward putting new notes > on the wiki, so I wrote it in wiki format. R

Re: MTime resurrected

Alright, after the discussion on Friday I feel like I've got a better handle on the subject, so I went ahead and tried to document the intended behaviour. I noticed that you seem to be moving toward putting new notes on the wiki, so I wrote it in wiki format. -Rick- =Design: MTime Preservat

Re: MTime resurrected

Philip Martin writes: > We have a new flag and a new mode, so the new behaviour can be almost > anything. Why is is acceptable to ignore mtime-only changes? It makes > no sense to me. It might be acceptable as an experiment but really it's > a half-baked solution. Perhaps that came across as

Re: MTime resurrected

Rick Yorgason writes: > and I was picturing it as: > > * Commit always sends the text-time. > * Updates only use the text-time if (a) it doesn't affect the current > workflow, or (b) the user explicitly asks for it. > > I think the second option is safer, since it's easier to change your > mind i

Re: MTime resurrected

On 17/02/2012 9:55 AM, Philip Martin wrote: The defailt behaviour is not the thing that is blocking progress. What is blocking progress is saying things like "leave that option out until..." rather than working out how it should behave and be implemented. Okay, we have a misunderstanding here

Re: MTime resurrected

Rick Yorgason writes: > So if you add the option to treat mtime-only changes as modifications, > I definitely don't think it should be the default option. It's also > probably safe to leave that option out until some squeeky wheels speak > up. It's not an option, it's an important decision that

Re: MTime resurrected

On 2012-02-17 9:06 AM, Julian Foad wrote: I wouldn't call that email a "design worked out". My reply to that email posed a load of questions and issues to be clarified or re-thought, and wasn't answered AFAICT. Other people did the same and did get some more discussion in that thread, but the

Re: MTime resurrected

On 2012-02-17 7:21 AM, Philip Martin wrote: - mtime only changes. The old branch treated a file with only an mtime change as unmodified: it did not show up in status or diff and did not get committed. That was convenient from an implementation point of view, but hard to justify otherwi

Re: MTime resurrected

Rick Yorgason wrote: [...] > Before anybody calls me out on this, my suggested heuristic for setting the > local timestamp is not intended to solve all of these problems. I'm > advocating the design worked out by Edmund Wong and Philipp Marek: > > http://svn.haxx.se/dev/archive-2010-02/0127.sht

Re: MTime resurrected

On 2012-02-17 6:41 AM, Fuhrmann Stefan (ETAS/ESA1) wrote: I'm not championing the mtime feature but if someone demonstrates a compelling use-case, it should neither be hard nor risky to implement it. -- Stefan^2. There have been quite a lot of use cases presented over the years. A is mine; B

Re: MTime resurrected

"Fuhrmann Stefan (ETAS/ESA1)" writes: > But since we already have an (optional) feature > that will use "older" timestamps, I don't see why > optionally preserving mtime would be too hard. > The only potential problems that came to my mind > were sync'ing the wc.db with mtime upon commit > and cl

RE: MTime resurrected

Bert Huijben wrote: > Fuhrmann Stefan (ETAS/ESA1) wrote: > > Peter Samuelson wrote: > > > Now do a 'svn update' or 'svn switch' which changes foo.c. > > > > > > Current svn: foo.c mtime is set to the present time. It is now newer > > > than foo.o. [Of course you can set foo.o's mtime in the futur

Re: MTime resurrected

On 2012-02-17 4:34 AM, Bert Huijben wrote: -Original Message- From: Fuhrmann Stefan (ETAS/ESA1) [mailto:stefan.fuhrm...@etas.com] Sent: vrijdag 17 februari 2012 9:27 To: dev@subversion.apache.org Cc: r...@longbowgames.com; pe...@p12n.org Subject: Re: MTime resurrected Peter Samuelson

RE: MTime resurrected

> -Original Message- > From: Fuhrmann Stefan (ETAS/ESA1) [mailto:stefan.fuhrm...@etas.com] > Sent: vrijdag 17 februari 2012 9:27 > To: dev@subversion.apache.org > Cc: r...@longbowgames.com; pe...@p12n.org > Subject: Re: MTime resurrected > > Peter Samuelson

Re: MTime resurrected

Peter Samuelson wrote: > Now do a 'svn update' or 'svn switch' which changes foo.c. > > Current svn: foo.c mtime is set to the present time. It is now newer > than foo.o. [Of course you can set foo.o's mtime in the future, but > that's just breaking things _on purpose_.] Ahem. At least with 1

Re: MTime resurrected

[Rick Yorgason] > Wouldn't an acceptable default be to always update the local file > time to the text-time, except when the local file time is newer? > (i.e. Ensuring that the time never goes backward, even on a switch or > revert.) > > That would never screw up a build system Eh? It would scr

MTime resurrected

So, I've found myself needing the MTime extension that's been under discussion since 2003 (Issue #1256) and just spent some time reading the various posts associated with it. In 2010 Edmund Wong wrote a nearly complete spec for mtime preservation, after which some discussion narrowed it down,