[texworks] external read-access causes TeXWorks to revert open file to old version

[Stefan Löffler]

Hi,

Am 2010-11-01 23:01, schrieb Stefan Müller:
> On 01.11.2010 19:05, Stefan Löffler wrote:
>> Yes, this seems to confirm my theory.
>> First of all, you should get the "Changed" line only if the file is
>> actually being reloaded. Which it shouldn't be, if the file wasn't
>> changed externally - that's the whole point ;).
>> Now, the fact that Tw prints a later time-stamp during a positive run
>> than a subsequent invocation of `ls` suggests that the file is indeed
>> written twice. First the file is changed during the commit, which Tw
>> picks up. Then, the original file (with the earlier timestamp) is
>> restored, but Tw doesn't pick that up (probably because it is still
>> processing the first change). As such, this naturally only happens
>> occasionally (if mercurial takes a certain time to process the commit).
>>
>> Unfortunately, I don't see a quick fix for this. One thing would be to
>> never reload a file unasked. This would be a bit of an inconvenience for
>> "normal" users, though. Another possibility would be to process the
>> updates in a separate thread, thereby keeping track of all changes. Or
>> to check the file state again after the loading (and rerun the reload
>> method in case the file has changed again in the meantime). This last
>> option strikes me as the safest one.
>
> It seems somewhat strange to me, that TW reloads the file unasked if
> something changed on disk. E.g. it may be the case that I replaced the
> file by accident or something. I know at least some applications that
> ask me when this happens. Strangely, TW once asked me that, too. I
> think it was a (strange) "positive" run.

Well, yes and no. Tw does ask the user if the file in question has
unsaved changes in the editor, of course. So it never discards unsaved
changes. If there are no changes, however, (i.e., the contents of the
editor reflects exactly the file on the disk) the ratio is that if
someone uses an external editor or something to change that file, he'd
expect that change to reflect in Tw. But of course always asking would
be another possibility to resolve this...

>> Have you been in touch with the mercurial people? Did they say anything
>> about the two stages of the commit?
>
> I did not contact them because I thought I first talk to you guys and
> see what you come up with. I'll check tomorrow if I can find a
> TortoiseHG mailing list or something and show them this thread.
>
> Indeed, I don't understand why the file changes anyway during a
> commit. I always thought it is read-only. This should have to do
> something with TortoiseHG. I assume that TW doesn't see ghosts or
> something.

I'm not a mercurial specialist - maybe a TortoiseHG mailing list can
help you there. I can only imagine what might happen:
1) hg commits the changes to the repository (no matter if it's local or
remote)
2) since the current working copy is now out of sync with the repository
(at least as far as meta-data is concerned), some sort of update is
required; first hg will save any uncommitted changes somewhere...
3) ...and then sync the working copy with the repository, thereby
overwriting every file and directory that is in the repository (this
would explain why Tw picks up the timestamp from the commit)
4) And finally restore uncommitted changes as saved in step 2, thereby
also restoring the original timestamp as `ls` picks it up afterwards.

-Stefan