[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: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 17 Feb 2012 16:41:58 +0000

Rick Yorgason <rick_at_longbowgames.com> 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 in the future than it is to change your mind in the past. Am I
> missing some way in which this affects current workflow?

Not just safer, the second option is the only acceptable option. Update
cannot use the recorded text-time by default as that will break things
like make. So the user needs to explicitly request the new behaviour by
setting something like use-modified-time=yes.

> With that in mind...
>> It's not an option, it's an important decision that is intrinsic to the
>> implementation. So you can't "leave that option out until ...".
> Originally I thought you were proposing that users would install svn
> 1.8, try to commit something, and find that a file has been marked as
> modified when it was an mtime-only change. This affects current
> workflow, so I disagreed with it.
> From my point of view (the "decide on update" view) there's two options:
> A) Don't count mtime-only updates as modifications.
> B) Only count mtime-only updates as modifications if the user
> explicitly asks for it.
> I was proposing the simpler option, which is A.

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.

uberSVN: Apache Subversion Made Easy
Received on 2012-02-17 17:42:36 CET

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