Again, that can be handled with WebDAV. GIT can store its repository on
a WebDAV server. A WebDAV interface to the content component could be
designed.
-Adrian
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?
