#2 First commit to fresh repository fails

[mstammberger]

If a new repository is created the very first commit will fail with an error:

ProgrammingError: calling set_tracked outside of a changing_files
Traceback (most recent call last):
File "hg", line 58, in <module>
File "mercurial\dispatch.pyc", line 143, in run
File "mercurial\dispatch.pyc", line 232, in dispatch
File "mercurial\dispatch.pyc", line 276, in _rundispatch
File "mercurial\dispatch.pyc", line 457, in _runcatch
File "mercurial\dispatch.pyc", line 467, in _callcatch
File "mercurial\scmutil.pyc", line 153, in callcatch
File "mercurial\dispatch.pyc", line 447, in _runcatchfunc
File "mercurial\dispatch.pyc", line 1272, in _dispatch
File "mercurial\dispatch.pyc", line 905, in runcommand
File "mercurial\dispatch.pyc", line 1284, in _runcommand
File "mercurial\dispatch.pyc", line 1270, in <lambda>
File "mercurial\util.pyc", line 1881, in check
File "mercurial\util.pyc", line 1881, in check
File "hgext\mq.pyc", line 4227, in mqcommand
File "mercurial\util.pyc", line 1881, in check
File "mercurial\commands.pyc", line 6696, in serve
File "mercurial\server.pyc", line 166, in runservice
File "mercurial\commandserver.pyc", line 461, in run
File "mercurial\commandserver.pyc", line 395, in serve
File "mercurial\commandserver.pyc", line 369, in serveone
File "mercurial\commandserver.pyc", line 350, in runcommand
File "mercurial\commandserver.pyc", line 289, in _dispatchcommand
File "mercurial\dispatch.pyc", line 232, in dispatch
File "mercurial\dispatch.pyc", line 276, in _rundispatch
File "mercurial\dispatch.pyc", line 457, in _runcatch
File "mercurial\dispatch.pyc", line 467, in _callcatch
File "mercurial\scmutil.pyc", line 153, in callcatch
File "mercurial\dispatch.pyc", line 447, in _runcatchfunc
File "tortoisehg\util\hgdispatch.pyc", line 27, in _dispatch
File "mercurial\dispatch.pyc", line 1272, in _dispatch
File "mercurial\dispatch.pyc", line 905, in runcommand
File "mercurial\dispatch.pyc", line 1284, in _runcommand
File "mercurial\dispatch.pyc", line 1270, in <lambda>
File "mercurial\util.pyc", line 1881, in check
File "mercurial\util.pyc", line 1881, in check
File "hgext\mq.pyc", line 4227, in mqcommand
File "mercurial\util.pyc", line 1881, in check
File "mercurial\util.pyc", line 1881, in check
File "tortoisehg\util\partialcommit.pyc", line 42, in partialcommit
File "mercurial\util.pyc", line 1881, in check
File "mercurial\commands.pyc", line 2101, in commit
File "mercurial\commands.pyc", line 2213, in _docommit
File "mercurial\cmdutil.pyc", line 2944, in commit
File "mercurial\commands.pyc", line 2203, in commitfunc
File "hgext\mq.pyc", line 4117, in commit
File "C:/Program Files/TortoiseHg/Extensions/TimestampMod.py", line 205, in Wrap_Commit
timestamp_mod(
File "C:/Program Files/TortoiseHg/Extensions/TimestampMod.py", line 517, in timestamp_mod
_save_TimestampsJSON(
File "C:/Program Files/TortoiseHg/Extensions/TimestampMod.py", line 1036, in _save_TimestampsJSON
repo[None].add([IN_TimestampFileName])
File "mercurial\context.pyc", line 1722, in add
File "mercurial\dirstate.pyc", line 85, in wrap
File "mercurial\dirstate.pyc", line 106, in wrap
mercurial.error.ProgrammingError: calling set_tracked outside of a changing_files
cmdserver: process exited unexpectedly with code 255</lambda></lambda></module>

Unknown exception encountered with possibly-broken third-party extension "TimestampMod" 0.3.4 which supports versions 5.9 of Mercurial.
Please disable "TimestampMod" and try your action again.
If that fixes the bug please report it to https://sourceforge.net/p/timestampmod/tickets/
Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
Mercurial Distributed SCM (version 6.5.1)
Extensions loaded: TimestampMod 0.3.4, histedit, mq, rebase, strip, tortoisehg.util.hgcommands 6.5.1, tortoisehg.util.hgdispatch 6.5.1, tortoisehg.util.partialcommit 6.5.1, tortoisehg.util.pipeui 6.5.1, tortoisehg.util.win32ill 6.5.1, transplant
[Code: -1]

(I edited the output a bit to make it more readable).

After fiddling a bit around to find a workaround if realized that this happens due to the missing .hgtimestamp file after the hg init.

Steps to reproduce the bug

• Create a new repository (hg init)
• Add one or more files. They are then marked as 'A'.
• Trying to perform a commit of these files then fails in TimestampMod (see error message above).

Next steps to workaround the bug

• Now forget the files. This will create the file .hgtimestamp
• Add the files again (+ the not yet added file .hgtimestamp! Otherwise the commit will fail again!
• Now commit will succeed!

[nedmech]

@mstammberger, thanks for bringing this to my attention. It's good to know this extension is still getting some use.

This is another under-the-hood change in Mercurial that is going to be tricky to accommodate. I suspect that this error would show up using Mercurial 6.4 or later on any repo (new or existing) when the TimeStampMod extension is first set up in Mercurial for that repo. It looks like the first commit that tries to automatically add the .hgtimestamp file to the repo will trip over this. Adding it manually avoids the issue.

Possible alternative steps to avoid the issue until a resolution can be found:

This should bypass the issue more cleanly than calling forget to generate the timestamp file and then manually adding it.
* Create a new repository (hg init)
* Add one or more files to the repo.
* Manually issue the hg timestamp_mod -s command. This saves the timestamps and adds the .hgtimestamp file to the repo. (NOTE: This should work even if there are no files in the repo yet.)
* Commit as usual. This should bypass the error since the file is already added to the repo by the manual timestamp save command.

Developer Notes:

• The error is where the timestamp file is automatically added to the repo if it hasn't been added yet.
• This call is inside the context of the Wrap_Commit method, which was an admittedly "dirty" implementation, but the normal pre-commit hook failed to work when used with TortoiseHg.
• The repo[None].add(...) method was used since this is the same method used internally by Mercurial when creating the .hgtags file (was in localrepo.py, now looks like it's in tags.py).
• the set_tracked method called by .add(...) now has a guard-clause that kicks it out unless the changing_files condition is true (as of Mercurial 6.4).
  • This makes creating a backwards-compatible fix for this difficult since the changing_files condition did not exist prior to 6.4.

Change to test:

This doesn't work with older version of Mercurial prior to 6.4, but this may resolve the issue for newer versions. Need to test with Mercurial 6.4 or later.

In _save_TimestampsJSON at line 1036:
remove:

        repo[None].add([IN_TimestampFileName])

add:

        with repo.dirstate.changing_files(repo):
            if (IN_TimestampFileName not in repo.dirstate):
                repo[None].add([IN_TimestampFileName])

I'll try to get this tested on my home computer over the weekend since we're still on 5.0.2 at work. It's going to take a little more tweaking to make this backwards-compatible too even if it does work.

[nedmech]

@mstammberger, I think I've got a fix for this. Please download and test the extension file from the tip of my development branch when you have an opportunity. It seems to address the issue on my Win64 machine using TortoiseHg, but it would be good to verify that it fixes it on your environment as well.

[mstammberger]

It works! Thank you for the really quick fix of the issue!

[nedmech]

Glad it worked and wasn't too difficult to patch the issue.

[nedmech]

Re-opening this ticket. This issue is still present when committing recursively into subrepositories (--subrepos).

This likely will take some exploring to resolve. In the short-term, committing changes within the subrepo before committing the subrepo state in the parent still seems to work without errors. It's just the recursive commit that is currently broken.