Rick Yorgason <r...@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
