On 8/7/2006, at 13:16, Mats Persson wrote:
[...] The above seem to indicate that I should just have another copy of the Support stuff from the SVN locally, and that needs to be updated on a regular basis in order to stay ahead of your version in the app. It would also seem to mean that I would have to inflict my version of the .css on everyone else, just to have the version that I like.
Why would your local changes have to be inflicted on others?
Did I get that correctly ? IF so, then a much better version would be to look for the local Support dir / file and IF found then use that, else use the default version regardless of version number or anything like it.
I don’t fully understand -- are you saying you don’t want TM to respect the newly introduced version file, so that you can have local changes w/o having to ensure that the files you haven’t modified are up-to-date?
The last month(s) has seen dozens of support questions from people who had an old support folder but bundles which relied on the latest version -- thus I introduced this version number.
I reckon what you’re really after is moving CSS out of the support folder and make a separate system to deal with CSS customizations. Currently though a lot of bundles ship with their own CSS, so I don’t know how much would actually be gained from that.
If the CSS was factored out, there is however still the problem with versioning and keeping up-to-date. E.g. the Status command in the Subversion bundle is currently going through major stylistic changes -- if anyone had a local version of the Subversions CSS folder which eclipsed the default one, he would probably get a rather screwy visual result when he got the new command (but not CSS.)