Re: MTime resurrected

On 2012-02-17 7:21 AM, Philip Martin wrote:
> - mtime only changes. The old branch treated a file with only an mtime
> change as unmodified: it did not show up in status or diff and did not
> get committed. That was convenient from an implementation point of
> view, but hard to justify otherwise. I think mtime only changes
> should be treated as modifications.

Based on the use cases I posted in my last email, I think all of them
would either be ambivalent to the decision, or would prefer treating
them as modifications.

Outside of those use cases, there's definitely some situations where
treating them as modifications would annoy people used to the status
quo. Log files and compiler-generated files spring to mind.

So if you add the option to treat mtime-only changes as modifications, I
definitely don't think it should be the default option. It's also
probably safe to leave that option out until some squeeky wheels speak up.

> - merge conflicts. The property will often conflict on merge, some
> automatic resolution is probably required. I think the old branch
> ignored this problem.

I think it needs to be automatically resolved, but I don't think it
matters how it's resolved. Obvious choices would be:

A) now()
B) the latest of the two times
C) delete the property

Merging necessarily modifies the local file, so no matter which
resolution you pick, you'll get a new text-time the next time you commit.

-Rick-
Received on 2012-02-17 15:08:44 CET