Rhizomes, Databases, and Heidegger

[rax]

The title makes this sound boring, but bear with me. It's going to be ridiculous and really boring instead. Also I am submitting this as homework but I am writing it primarily for this audience and my class can deal with it. (Also this is an attempted edited version from what I posted last night, particularly in the last two paragraphs.) So:

Deleuze

Comments

[csbermack]

I follow relatively little of either, but it reminds me of the conflict over what kind of version control system to use. There's a thing... I blank on the name but I bet you know it... where instead of a centralized database that contains All The Knowledge, and when you take a copy you then later have to compare it to that database (which conveniently uses terms like "trunk") before you add your knowledge.

The other thing is basically everyone's desktop has its own version of The Knowledge, and it differs from other desktops and then you have to reconcile the various desktops but none of them contain All The Knowledge, they all just contain Knowledge. Presumably in the background they all talk to each other and update each other, and I do not understand resolving conflicts. But at a previous workplace, a number of nerds were like "But this distributed model is the coolest thing ever and solves assorted problems" and looked down on people who were like "But I like having a server!" This seems different from the Cloud in how the user thinks about it, although I could be wrong in that maybe the Cloud is all just a version of this, not that I think anyone really knows what the Cloud is except people who are involved in lawsuits about it.

It makes me think of single point of failure and multinode installations and such, and I don't know what to make of all of it.

[greyooze]

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?