Closed (won't fix)
Project:
Configuration Management
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Oct 2012 at 21:14 UTC
Updated:
20 Nov 2013 at 13:18 UTC
Jump to comment: Most recent
Comments
Comment #1
dagmarD8 CMI doesn't have a rule for this. Some modules using a single file, others uses several files.
We 'could' save all the variables in a single file, same for permissions, but It needs some research because the whole system is designed to use a file per config.
There are Pros and Cons with the current system.
The main Pro is: developers will not be working in the same file if they are modifying two different permissions/variables.
The main Con is the amount of files that this system will generate.
Maybe we could provide two handlers and let users choose. I personally prefer the current system, but other developers could prefer have one file for all their variables and permissions.
Comment #2
dragonwize commentedCan you explain this more? Why would developers ever be touching the files? The module itself is the only thing we support to actually write the files and the module only writes what is in the DB so where does the conflict come up?
Comment #3
dagmarI was thinking in a team of developers working in a dev environment. If you have a single file that manages all the variables, a change in one variable, for example, one of pathauto, will override changes made for other developer working with the variable site-name.
Then developers have to coordinate their commits and reverts to avoid regressions.
Comment #4
lucascaro commentedGit usually handles edits on the same file pretty well, given that the file structure is clear enough, manual merges should be easy if needed.
If we want to rethink this (mabe for 7.x-2.1?) using a yaml file with var_name: 'serialized_value' with one variable per line would be a great way to manage variables, which would allow us to easily manage changes for different vars on the same file, and handle auto merges well.
Also we can have one less dependency (strongarm) which IMHO should be simple enough to replace and make the config files more easy to read and maintain.
Comment #5
codycraven commentedI concur, it is not the module's job to do version control. It is the module's job to support reverting UI changes (or exporting them) when they do not match the exports in the file system.
Comment #6
dagmar