{"thread":{"id":"25921","subject":"using git as a distributed content management tool","startedAt":"2010-12-02T01:47:34Z","lastAt":"2010-12-02T01:47:34Z","messageCount":1,"participants":["Adam Kellas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"157074","messageId":"id6tpm$sb4$1@dough.gmane.org","threadId":"25921","inReplyTo":null,"subject":"using git as a distributed content management tool","fromName":"Adam Kellas","fromEmail":"adam.kellas@gmail.com","sentAt":"2010-12-02T01:47:34Z","receivedAt":"2010-12-02T01:47:34Z","isPatch":false,"sender":{"key":"adam.kellas@gmail.com","avatar":null},"body":"I'm thinking of using git in a slightly unusual way and am looking for \nadvice or pointers. I'm developing a (GPL) tool which can be thought of \nas a generic content management system. The only thing that matters here \nis that it generates a related set of potentially binary files. My \ncurrent \"persistence solution\" is a typical Java server backed by a \nrelational database but while reading about git in another context, and \nin particular about how it's really a general content-addressable \nfilesystem which just happens to be tuned for SCM, I started thinking \nreplacing that back end with something based on git. Essentially this is \nthe same old DVCS-vs-centralized question except the tool is not exactly \na VCS. The results would be shared via the usual push/pull git semantics.\n\n From what I see of git plumbing this looks eminently doable, and I \nthink it will almost certainly work if each user is given their own repo \nas in normal git usage. What I'm trying to figure out is whether an \noptimization is possible: I'd like to support a model where a repo is \nshared between a number of instances of my tool running on the same \nmachine or even on the same network as long as the repo is available via \nNFS, which raises issues like race conditions and locking that don't \ncome up for a developer using his/her own repo.\n\nSpecifically here's what I'm thinking: each instance would set GIT_DIR \nto point to the common repo, and GIT_INDEX_FILE to a per-instance temp \nfile. Then, as artifacts are generated they can be stored as blobs using \nhash-object and entered into a tree using create-tree. Note here that \nblobs would go directly into the shared repo while trees would be in the \nprivate index file. Then at the approriate time the tree can be \n\"published\" via commit-tree. It would be available immediately to other \nusers of the shared repo and could be pushed or pulled asynchronously \nfrom there.\n\nSo, assuming permissions are set to allow it, is there a problem with \nthis? I see a possible race in creating blobs iff they happen to be \nidentical and another at commit-tree time. Does git do any locking of \nits own or would I have to implement my own around these?\n\nThanks,\nAK\n"}]}