As soon as you see a table most computer programmers probably think about databases. And that's probably right, many times. But always?

In a table we manage a set of rows with a key or id field. If the table is small, say less than 10.000 the science of implementing them gets less problematic and you can solve the problem with a lot of different ways. Typically you have a database and n useres that interact with the database and your application live with the contact with the database.

Is there any other way? Well what I'm thinking about is distributed development of open source softwares around a git or similar vc repository. You don't have access to servers easilly that fronts the internet and also you want the users to be able to work off-line. Wouldn't it be nice to just reuse the distributed vc for project management as well and that's the simple idea.

So consider a table beeing a directory in the git tree and the rows serialized into files. Is this a challange to maintain? What sematicas are there

1. We have a local application that closed saves the current latest checked in version in one file.
2. At startup of the local application, the system loads the state and then looks at the repo for all changed entries that is uppon that state and adds it to the correct current view of the table. 2.5 If there is no local file then read the entries in the git tree in all 1,2,2.5 means that the startup of the local application is fast and we mainly use the git tree to communicate and maintain version control of it and also make sure to communicate just diffs.
3. each user generates their own id, like stis-1. stis-2. ...
4. when addding or changing a new row it is mimiked in a changed file added or removed in the git repo.
5. when updating the repo, the local application looks at the diff and updates accordingly.
6. the only security should be to agree an a role. If there is sensitive data for just a subgroup then don't enter it in a public git repository, make a special repository for that and make a table that wraps the two underlying tables. So we shouled be able to consider multiple git repositories in the same view and application using the table should facilitate in combinining them.

A good example to put in your source git repo is project management information. For eample an issue tracker and release planner with associated meta information like references to git commits, documentation, test-code in test suits, who created the issue, who is assigned tho the issue, what state it is in, like analyze, implementing, verifying, finished, links to releases planned etc stuff i find in the tools we use at work for managing software projects.

So what I plan to do is to create two project. One for the infrastructure of embedding tables into git trees and one for project management. I think it is wise to have an application as well as an