add lock id to node for collaboration in documents

[Andronimo]

This is a proposal for a locking mechanism for nodes to allow collaboration in a network document.
I use 32 bit of the readonly property in the sqlite database for a lock id, which tells us who locked the node. The id is created on the first startup of cherrytree and stored in the config.
You can acquire/release the lock of a node in the tree popup menu. If another user holds a lock on a node or a parent node it's like a readonly node for user users.

TODO:

1. visualization of locked nodes
2. restrict operations on locked nodes (e.g. hierarchy changes are not allowed if you don't have a lock on the parent)
3. save document after user changes a lock
4. read locks from other users when document on disk changes
5. ...

[giuspen]

Interesting, I would rather use an external file for lock/unlock though and not the document file itself, this way would work for all the 4 document types...

[giuspen]

Oh you talk about nodes sorry I thought the whole document

[Andronimo]

Yes the idea is that all team members can work in the same document. We often need this for software design or requirement engineering.
This can be done by locks on nodes. Content changes on subnodes and hierarchy changes on the same level have to be restricted.

[giuspen]

Have you tested the same SQLite database opened from multiple terminals/people and written concurrently from multiple terminals/people?
I haven't investigated yet but I suspect that SQLite does not support that

[Andronimo]

I tested it on an nfs drive with all machines running Ubuntu and it worked quite well. When a process was writing to the database, another process returned that the database is locked.
Nevertheless it highly depends on the used network share implementation. There are buggy NFS versions out there and on cifs the database appears to be always locked.

[ajaxStardust]

(sorry to chime in like this. new to GitHub in the context of collaboration. probably a faux pas)

I just wanted to say it's impressive the power / potential energy in CherryTree, and this proposal is a great idea!
:)

[giuspen]

It is in the plans in future to support some kind of collaborative edit on the new document type multifile