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
