>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3561263. --> Reported by: [yautja_cetanu](https://www.drupal.org/user/626050) >>> <p>[Tracker]<br> <strong>Update Summary: </strong>[One-line status update for stakeholders]<br> <strong>Short Description: </strong> Blue Sky thinking for approaches to Workspaces for Config.<br> <strong>Check-in Date: </strong>MM/DD/YYYY<br> <strong>Additional Collaborators: </strong><br> <em>Metadata is used by the <a href="https://www.drupalstarforge.ai/" title="AI Tracker">AI Tracker.</a> Docs and additional fields <a href="https://www.drupalstarforge.ai/ai-dashboard/docs" title="AI Issue Tracker Documentation">here</a>.</em><br> [/Tracker]</p> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Databases don't do branching and revisions very well, especially configuration in databases, especially because everything is so interconnected. So doing this is tough.</p> <p>We also need Config and Content in a workspace. So you might have a landing page that adds a new fields to an entity, makes it required, creates a new piece of content using that field, also edits an existing piece of content (requiring that field to be populated), they may put a block in that landing page using a new block type, a new view, or even webform and might even add new modules. </p> <p>We need some way we can track all these changes across all these different modules, and then allow for branching and merging so that an end-user can actually see whats going on and make a call. (What if two branches make the same field but with slightly different names, now content needs to be merged, what about two select lists which slightly different wording of one or two items?)</p> <p>So some ideas:</p> <ul> <li>We could create new content types with a name convention that is a clone and work on that.</li> <li>We could create new database tables with a name.</li> <li>We'd need to clone the whole database or allow views to make a mixture of changed fields and old fields</li> <li>We could move to putting things in flat files (Config used to do this) where we use actual git.</li> <li>Maybe pages that have changes in a workspace are written to a flat file system using JSON to store the content instead of the database. (But then views, etc needs to know this is happening).</li> </ul> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <h3 id="summary-remaining-tasks">Target date or deadline</h3> <h3 id="summary-remaining-tasks">Remaining tasks</h3> > Related issue: [Issue #3493461](https://www.drupal.org/node/3493461) > Related issue: [Issue #3561258](https://www.drupal.org/node/3561258)