Issue #81 new

Abort: file not tracked! on Windows

Benoît Allard
created an issue

I suspect a timing issue, as if I look at the repository after the trouble, the file is well marked as added ...

This prevent the user to enter any comment.

hg 2.0.2 from TortoiseHg.



Traceback (most recent call last): File "c:\tools\hg-review\bundled\flask\flask\", line 965, in call return self.wsgi_app(environ, start_response) File "c:\tools\hg-review\bundled\flask\flask\", line 955, in wsgi_app response = self.make_response(self.handle_exception(e)) File "c:\tools\hg-review\bundled\flask\flask\", line 952, in wsgi_app rv = self.dispatch_request() File "c:\tools\hg-review\bundled\flask\flask\", line 754, in dispatch_request return self.view_functionsrule.endpoint File "c:\tools\hg-review\review\", line 181, in changeset return _handle_comment(revhash) File "c:\tools\hg-review\review\", line 170, in _handle_comment rcset.add_comment(body, ufilename, filename, lines, style) File "c:\tools\hg-review\review\", line 526, in add_comment comment._commit(self.ui, self.repo) File "c:\tools\hg-review\review\", line 799, in _commit { 'message': self.commit_message % self.node, 'addremove': True, }) File "mercurial\", line 1223, in commit

File "c:\tools\hg-review\review\", line 146, in _commitfunc return repo.commit(message, opts.get('user'), opts.get('date'), match) File "hgext\", line 3117, in commit

File "mercurial\", line 1090, in commit

File "mercurial\", line 1016, in fail

Abort: cd2c3ccbceffccf5063816d428a6511d8e848a72/comments/c284e52c68e168667a7a014ddf4d9982cd53d776: file not tracked! }}}

Comments (6)

  1. Joel B Fant

    I don't think it has to do with timing. I could reproduce it, and then I stopped using the web UI to see if using the CLI did the same thing. It did, and I found something interesting. The current directory was in the parent repo, say C:\myapp. Here's the output when I did hg review --comment (node_id and comment hash replaced for brevity):

    117»  hg review --comment -m 'my message' --mdown -r <node_id>
    adding hg\review\<node_id>\COMMENTS\<cmt_hash>
    abort: <node_id>/comments/<cmt_hash>: file not tracked!

    So then I played around with passing variations of the file's path to hg commit manually to see what happened...

    118» hg -R .hg\review ci -m 'test' <node_id>/comments/<cmt_hash>
    abort: <node_id>/comments/<cmt_hash> not under root
    119» hg -R .hg\review ci -m 'test' .hg/review/<node_id>/comments/<cmt_hash>
    abort: <node_id>/comments/<cmt_hash>: file not tracked!
    120» hg -R .hg\review ci -m 'test' .hg/review/<node_id>/COMMENTS/<cmt_hash>

    Wait, why did changing the case of comments to match what was in the "adding" message make a difference? I don't know enough Python or internal Mercurial API to figure out the solution there, so what I did that managed to get it working is probably more of a workaround:

    I had been looking at hg-review/review/ while attempting to figure this out. In various places -- like on line 794 in _ReviewObject._commit() -- it calls cmdutils.commit() and passes both a specific filename and the addremove option. I figured, if it's going to use addremove, then specific filenames don't matter. So I replaced [objectpath] on line 795 with [] and the "file not tracked!" error didn't occur for that test anymore. I also modified a few other instances of cmdutil.commit() to pass [] instead of specific filenames and it seems that hg-review runs fine now.

  2. Benoît Allard reporter

    The trouble with the proposed solution is that every modification to the review repository will be commited, not only the comment/signoff/... being worked at.

    Anyway, you spotted the issue as being a case issue, and I can confirm it, while not in the way you confirmed it, but almost. Here are my finding:

    repo.walk() in the cmdutil.commit() function inside mercurial returns the file name with capital letters in the hash. That one get added to the repository in scmutil.addremove(). When mercurial then tries to commit the given path, is has not been added to the repository, and returns with the known error message.

    The following extract of the python shell on the werkzeug marvelous debug interface shows it:

    >>> objectpath
    >>> repo.walk(repo[None].match([objectpath]))

    The bug looks like an internal bug of mercurial to me.

    The funny part, I cannot reproduce it on the command-line ...

  3. Joel B Fant

    Under normal usage, I didn't see --addremove as an issue. However, I tinkered a bit more and using an include pattern of the exact file path seems to work as well. It didn't add any miscellaneous files I added to the review repo. So here's that patch.

  4. Log in to comment