Issue #42 resolved

'NoneType' object has no attribute 'files' on commit subrepos

Michael Stammberger
created an issue

Committing all changes done in some subrepos with option --subrepos fails with error 'NoneType' object has no attribute 'files'

Command line and output:

App% hg commit --verbose --user "xyz@xyz.com" "--message=foobar" --subrepos -- "G:\Projects\App\main" "G:\Projects\App\SubRepo1" "G:\Projects\App\SubRepo2" "G:\Projects\App\SubRepo3"


TimestampMod|Wrap_Commit accessed!

Executing timestamp_mod function

------ Saving timestamps to JSON file...

TimestampMod|Wrap_Commit finished!


committing subrepository SubRepo3


TimestampMod|Wrap_Commit accessed!

Executing timestamp_mod function

------ Saving timestamps to JSON file...

'NoneType' object has no attribute 'files'

Setup:

  • TimestampMod 0.2.7

  • TortoiseHg 2.8.1

  • Mercurial 2.6.2

  • Python 2.7.3

  • Qt 4.8.4

  • Windows XP

Comments (9)

  1. Nathan Durnan repo owner

    The good news: I am able to recreate this error on my machine, so I should be able to fix it.

    The bad news: I've "fixed" this problem before! Originally to address Issue#25 for the same error. And most recently while updating the extension for Linux compatability (Issue#40).

    My thought is that something I did while updating the extension for Linux has caused the handling of the match object to be broken when used with Subrepositories. I have checked the previous version (0.2.6) for this issue, and it does not appear to have the same problem.

    Since you are using this in Windows and not Linux, dropping back to the previous version should temporarily get you past this problem. You can download it from the "Downloads" tab, or this direct link:

    TimestampMod_0.2.6.py

    Just make sure to rename it without the '_0.2.6' when you set it up.

    I will attempt to resolve this issue this week. Unfortunately, I do not have as much time to devote to this project as I used to. Please be patient while I try to balance this with my existing workload.

  2. Michael Stammberger reporter

    I have already read the issue #25, but I thought, it's a different error because the error message was not exactly the same.

    BTW: The same error appears if you try to use the graft command. In this case you don't need any subrepos to reproduce it.

    Switching back to TimestampMod 0.2.6 works for the moment.

  3. Michael Stammberger reporter

    The graft command works now correctly with 0.2.8 rc.

    Concerning the commit/subrepos issue I'm a little bit confused:

    Yesterday I did a commit (with --subrepos) on a parent repository with 3 changed subrepos. The commit performed well for two of them, but the third wasn't committed correctly:

    After that commit TortoiseHg was displaying the subrepo still as "changed subrepo", but there weren't any changed files anymore. There were no error messages at all. After performing the commit once again this subrepo was committed.

    I'm not sure, if TimestampMod was the reason or TortoiseHg/Mercurial has failed for any reason. Unfortonately I wasn't able to reproduce this behaviour.

  4. Nathan Durnan repo owner

    Michael Stammberger: Thanks for testing the RC for me. It sounds like the issue has been addressed.

    Is there any way you can share your repository/subrepo's with me so I can try to help diagnose what is happening with your --subrepos commits? I'm curious what the conditions around the missing subrepo commit are. It sounds like the subrepo actually took the commit internally, but the state change didn't get picked up by the main repo. I vaugely remember running into something like this in the past, but can't recall any specifics. Maybe a look at your repo's will jog my memory.

    Other than the undetermined behavior, are you satisfied with performance of 0.2.8rc? If so, I will consider this issue closed and release 0.2.8 officially.

  5. Michael Stammberger reporter

    Sorry for late answering...

    Unfortunately I'm not allowed to provide the repository because it contains code of one of my clients. Of course I'll observe this strange behaviour and give you feedback if I get more details and if there is a relationship with TimestampMod.

    Concerning the original topic of this issue it seems to be solved. Since I moved to 0.2.8 rc I got no more errors.

    Thanks for your efforts and quick response!

  6. Nathan Durnan repo owner

    Closed with commit d335ca5 (I messed up the comment, so it didn't get into the tracking system automatically)

    I understand not being able to share your repo. I just thought I'd offer in case it was something I could help with. Thank you for your patience and for reporting the issue. I really rely on users for feedback to improve this tool. Feel free to create a new issue anytime you have a problem iwth TimestampMod.

  7. Log in to comment