I'm thinking of using git in a slightly unusual way and am looking for
advice or pointers. I'm developing a (GPL) tool which can be thought of
as a generic content management system. The only thing that matters here
is that it generates a related set of potentially binary files. My
current "persistence solution" is a typical Java server backed by a
relational database but while reading about git in another context, and
in particular about how it's really a general content-addressable
filesystem which just happens to be tuned for SCM, I started thinking
replacing that back end with something based on git. Essentially this is
the same old DVCS-vs-centralized question except the tool is not exactly
a VCS. The results would be shared via the usual push/pull git semantics.
From what I see of git plumbing this looks eminently doable, and I
think it will almost certainly work if each user is given their own repo
as in normal git usage. What I'm trying to figure out is whether an
optimization is possible: I'd like to support a model where a repo is
shared between a number of instances of my tool running on the same
machine or even on the same network as long as the repo is available via
NFS, which raises issues like race conditions and locking that don't
come up for a developer using his/her own repo.
Specifically here's what I'm thinking: each instance would set GIT_DIR
to point to the common repo, and GIT_INDEX_FILE to a per-instance temp
file. Then, as artifacts are generated they can be stored as blobs using
hash-object and entered into a tree using create-tree. Note here that
blobs would go directly into the shared repo while trees would be in the
private index file. Then at the approriate time the tree can be
"published" via commit-tree. It would be available immediately to other
users of the shared repo and could be pushed or pulled asynchronously
from there.
So, assuming permissions are set to allow it, is there a problem with
this? I see a possible race in creating blobs iff they happen to be
identical and another at commit-tree time. Does git do any locking of
its own or would I have to implement my own around these?
Thanks,
AK
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html