I think you are thinking of git, and you're right, it's a pretty good example of a rhizomatic database.
There is in fact still a database used in git (called a "repository") with a trunk and branches, but everybody has a copy of it rather than interacting with a central server. You would then also have a "working copy" of the source code which you've taken from your repository, and you make your changes in there. Once you're satisfied, you commit your changes to your copy of the repository database, which stores a record appropriately.
Then comes the clever bit. You can tell your copy of the database to synchronise itself with somebody else's copy: the two approaches are called "pull" (you get all change records they've added to their database and merge them into your own) and "push" (you send your new change records to them for merging). It is still possible to have conflicting changes which must be dealt with by hand, but that's an unavoidable problem really.
When a new person enters the project, they "clone" someone else's repository, which gives them a copy of the ENTIRE database according to the copy-ee. That means all the history of changes, trunk and branches, as well as the current state of affairs. It may not match the entirety of what ALL people have in their personal copies, but that's what the above synchronisation is for!
In practice a lot of projects have a "master" repository hosted on a server somewhere which everybody synchronises with, but that is more of a convenience measure than anything else. Anybody's personal copy of the repository could become a "master" copy if it was nominated to be so: there is no technical distinction, only a social one.
I have been thinking about this sort of thing a lot lately, I don't think we make enough use of this approach in computing. It seems similar to the way we manage knowledge amongst humans?
no subject
There is in fact still a database used in git (called a "repository") with a trunk and branches, but everybody has a copy of it rather than interacting with a central server. You would then also have a "working copy" of the source code which you've taken from your repository, and you make your changes in there. Once you're satisfied, you commit your changes to your copy of the repository database, which stores a record appropriately.
Then comes the clever bit. You can tell your copy of the database to synchronise itself with somebody else's copy: the two approaches are called "pull" (you get all change records they've added to their database and merge them into your own) and "push" (you send your new change records to them for merging). It is still possible to have conflicting changes which must be dealt with by hand, but that's an unavoidable problem really.
When a new person enters the project, they "clone" someone else's repository, which gives them a copy of the ENTIRE database according to the copy-ee. That means all the history of changes, trunk and branches, as well as the current state of affairs. It may not match the entirety of what ALL people have in their personal copies, but that's what the above synchronisation is for!
In practice a lot of projects have a "master" repository hosted on a server somewhere which everybody synchronises with, but that is more of a convenience measure than anything else. Anybody's personal copy of the repository could become a "master" copy if it was nominated to be so: there is no technical distinction, only a social one.
I have been thinking about this sort of thing a lot lately, I don't think we make enough use of this approach in computing. It seems similar to the way we manage knowledge amongst humans?