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

RE: MTime resurrected

From: Fuhrmann Stefan (ETAS/ESA1) <Stefan.Fuhrmann_at_etas.com>
Date: Fri, 17 Feb 2012 11:41:53 +0000

Bert Huijben wrote:
> Fuhrmann Stefan (ETAS/ESA1) wrote:
> > Peter Samuelson <peter_at_p12n.org> 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.7+ (and probably for a long time before that), a
> > c/o or update sets ctime=atime=now and mtime will be set commit time.
> > I.e. make *will* break if you update to older revisions.
>
> No, by default it does not.
>
> You only get this behavior if you enable use-commit-times in your Subversion configuration.

Sorry! You are right. It's just that the configuration
used in our company enabled that feature years ago.
I grew to actually like it.

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 clock / timezone issues.

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.
Received on 2012-02-17 12:42:37 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.