On 4 November 2011 01:45, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi, I think I can improve on Lex's recent proposal to split up project settings into two files, one for version control and one for local changes.
The problems with that are:
- How do we decide which settings are in each - e.g. build menu commands - a
project might want to override the make command in the VC settings file, but the user will want to add their own build commands too. There's a conflict. This becomes increasingly messy as we add project settings.
- Backwards compatibility - we would need to handle existing project files
anyway, which makes code more complex. I don't think we need to break compatibility.
- If the user changes a setting which is stored in the VC file they may end
up committing it, or perhaps sometimes not even realizing they are overriding the VC setting.
My solution:
A foo.geanystub project file goes in version control. It is never written to. It should be prepared by manually editing a copy of a local project file.
On opening a foo.geanystub file, Geany creates foo.geany in the same path then opens it.
When opening foo.geany, if foo.geanystub exists, then override settings with the stub contents.
This way the VC file can decide which settings are not overridable.
My solution shouldn't require much code to implement. I've only noted the bare bones of it, there are some things that could be added to make it better. Even with these I think it's simpler and neater.
Hi Nick,
I like simple, why don't we just add a setting to projects, say "based on", that allows a project file to import settings from another. Then the user project is "based on" the one in the VCS working directory. Simple and explicit and can adapt to any locations, on opening the project, settings are taken from the "based on" file if it exists and the setting exists unless it is overridden by the user project file. Based on is not recursive.
Note that this requires that projects not write a setting unless it is set by the user, that is not always the case now IIRC and is an added complication.
This way the VCS file is still a project file and can be edited using the Geany UI, albeit at the cost of writing session crap into it, but as that is overridden by the user session crap on next open so it doesn't matter.
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel