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

[Stefan Müller]

Hi,

I asked at the TortoiseHG list and someone pointed out what's going on. 
TortoiseHG enables me to select "hunks of changes", i.e. I can say I 
want to commit changes 3, 4, 6 and keep changes 1, 2, 5 uncommitted for 
the next commit (or whatever). To handle these types of commits 
TortoiseHG has to: backup all changes locally, revert the file, apply 
the changes for commit, commit, apply the other changes. That's why the 
file changes.

See 
http://tortoisehg.bitbucket.org/manual/1.1/commit.html#change-selection 
for an explanation of this feature.

So the file is changed 3 times if I understood this right. Is it 
possible for TW to detect every change of the files and not just the 
first? So that in the end the current version is restored? It seems to 
me that this should be possible without doing stuff like "wait 2 seconds 
before reloading after changes".

Stefan M.

On 02.11.2010 07:13, Stefan Löffler wrote:
>>> 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
>