Re-include is_root

[viktordick]

@Wiseqube Do you remember why you included this in the excluded keys? We now have a lot of systems yielding unstaged changes because of this. Was there a reason or was this an accident?

[Wiseqube]

@viktordick first I've heard of it (the unstaged changes, that is) I think the reason was, du to the fact that we also included a 'writeback' to the Data.FS on record I was getting this weird 'is_root' property on the git repos __root__/__meta__ file which was not there before, so since this was only a zodbsync internal key on the root object I excluded it.

[viktordick]

@Wiseqube But this is_root property was part of recordings in the past, why change this behavior?

[viktordick]

Not sure I understand your response. The is_root was included since the very beginning (the very first commit in 2015 of dbutils-zoperepo) and has been there since then, only changin the position at some point. With this change, it is no longer there - resulting in a superfluous change that yields unstaged changes and Generic Commit mails.

I guess you are saying that due to the writeback we now also have an is_root in the props list? I'll have to check that.

[Wiseqube]

Huh, ok then really not sure why... I thought that was the reason but I guess I'm wrong.

PS: No, I meant the key in the __meta__ file dictionary, so you are right saying that it has been there all along. I can't piece together a reason why this is there. Just confused why I have not seen the issues described yet somewhere.

[viktordick]

Checked it and there is no adverse effect of this PR, it simply restores the previous behaviour of adding an is_root field to the top-level element in the recording, avoiding unnecessary changes.

If you agree, could you approve? I'd create a new release and we can roll it out before too many systems are faced with this.

[Wiseqube]

LGTM