This is an interesting overview and while I'm not sure why I hadn't
thought along these lines before, at least it's through my thick skull
now...
I asked Adam about how this would deploy on multiple servers with the
stuff in the filesystem versus the database, and I think what you've
written Ean is the answer.
Why not treat a source repo (either plain SVN or something more exotic
like GIT) like the database? Each app server would read from and write
to the source repo just like it would a database record. If SVN or GIT
support 2-phase commits we could probably even do write operations in
the a transaction that includes connections to both data stores.
For performance reasons you'd want to cache content from the source
repo just like you would content from a relational database. If it's
really too terribly slow even doing that (ie reading directly from the
repo and caching) you could cache it locally in the app server's file
system, though it would probably be best to never write directly to
the local filesystem and you'd want some sort of timeout or other
logic to invalidate the file system cache just like you'd do with the
in memory cache (actually UtilCache supports this sort of thing,
though now with straight files in the filesystem, just a sort of mini-
database for local filesystem caching of data).
Anyway, is this something you guys have considered for WebSlinger?
For the OFBiz Content side of things you could pretty easily have a
DataResourceType for data in a source repo (ie instead of LOCAL_FILE
something like REPOSITORY_FILE). On the DataResource entity the
objectInfo field would have the URL/location of the resource (ie like
the SVN/HTTP URL), and we could add a field like "revisionNumber" to
specify which revision we want or null to get the head revision (I was
thinking we could use the existing ContentRevision/Item entities for
this, but looking at them it seems they wouldn't work so well and are
really meant for a revision control built on top of the Content and
DataResource entities, and not one that would describe revision
information pointed to by them). The "revisionNumber" could also go on
the Content entity so that we could have multiple Content records with
different revision numbers pointing to the same DataResource records
and reduce how many DataResource records we would require. That would
also better fit how Content and DataResource are meant to work
together, but on the other hand might be somewhat confusing.
Thoughts anyone?
Oh, one more thing... I know there are some Java libraries for SVN,
and there probably are some for GIT... has anyone played with these?
-David
On Jul 1, 2009, at 9:36 AM, Ean Schuessler wrote:
GIT excels at distributed workflows where parallel changes occur
between multiple parties and then must be merged back together. We
find
that this can happen a lot in real-world content development
situations.
Let's take, as an example:
- Us, with our development server
- A customer production server
- A development server in the customer's marketing department
- A development server in the customer's IT department
Then:
- Marketing is making content changes and we merge with them,
several times.
- IT works on a separate effort that they have not informed us about
but
merges in marketing changes.
- We build a tool for the marketing department that incorporates their
changes and we push back to them.
- IT pushes their merges to production.
- Marketing asks IT to merge our changes into production.
If you track content in the database I'm not sure how you can manage
this kind of workflow. If you create a unique prefix for each database
so that you can merge the entities then you will end up with
duplicated
party elements and other related roles. GIT, on the other hand,
manages
this (and much more complex) workflow with ease. We are looking at
laminating some kind of content entity metadata integration on top of
the revision control system based content but so far mostly store
content in the filesystem.
Al Byers wrote:
Could you please give a little more information about the type of
content
and merges that you see in practice, so I can see if the CMS could
be built
out to handle them?
--
Ean Schuessler, CTO
[email protected]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
