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. We both agree that existing
users should not have their workflow affected in any way by this new
feature, and I wasn't certain you agreed with that until now.

As far as I can tell (and let me know if I'm wrong) there's a fairly
fundamental difference between what we're envisaging: you see the
feature as:

* Commit only sends the text-time if the file passes some filter or option.
* Updates always use the text-time, if it's available.

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?

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.

> Forget about the default behaviout, that is not going to change (your
> last suggestion to allow mtime to move into the future causes problems
> for make, just like allowing mtime to move into the past).

The current behaviour already moves mtime into the future. Are there any
problems my proposal introduces that don't already exist?

-Rick-
Received on 2012-02-17 17:00:24 CET