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
http://www.uberSVN.com
Received on 2012-02-17 17:42:36 CET