It seems to me that there are areas where it is impossible to please everybody with a single solution. This thread is an example, the wiki-language is another, and probably there will be more. If Fossil develops a lot of private branches (like creole wiki) it will end up 'unix balkanised'. If everything becomes configurable options, it will end up a very complex tool with a bloated binary. There has to be a better way. Of the various "sub-systems" of Fossil, the ticket system is the most configurable. It uses a fexible schema, uses TH1 code to give users access to internals, and stores html/css for the UI. Perhaps this approach can be generalised for other components and uses. In order to make this work I'm thinking of the following: - a table to hold files related to customisation (css files, js files, TH1 script files, graphics files, etc. - hooks to call TH1 scripts - UI and command line access to the customisation files Example: unix/windows line endings - the default behaviour of Fossil would be as-is. - there would be a "pre-commit" and "post-checkout" hook - the pre-commit hook would be for instance a TH1 script to convert cr/lf to lf for certain files - the post-checkout hook would be for instance a TH1 script to do the reverse conversion Example: e-mail update notification - the default behaviour of Fossil would be as-is. - there would be a "mailto" primitive in TH1 - a pre-commit script could then send notification of new commits to selected users Example: other wiki-languages - the default behaviour of Fossil would be as-is. - there would be a wiki-view hook - a TH1 script would handle whatever wiki language to generate the equivalent HTML or: - the files for a wysiwyg wiki editor (eg. TinyMCE) could be stored in the custom files table Now where should the customisation table be? A first option could be as repository shared state. This is much the same as embedded documentation. However, this forces everybody to use the same customisation. The second could be as repository local state. Now everybody can have their own view of data. Problem here is that if you have many customisation files, you would have to manually enter all that configuration to each and every project you are working on. A third place could be the per user fossil file (.fossil / _FOSSIL), perhaps searched as a fallback location. Also, in the wiki-language example, the script must be part of the project itself, otherwise its wiki-pages would become unusable on other configurations. Does anybody have ideas on how to handle these storage/replication issues? Paul
________________________________ From: [email protected] on behalf of Ramon Ribó Sent: Wed 10/21/2009 6:47 PM To: [email protected] Subject: Re: [fossil-users] Developing on Unix and Windows > Frankly, though, probably not enough that I > would want to see such an ugly feature built into fossil. I also like beautiful things and hate ugly things. But life is sometimes difficult and it is better to fix problems instead of workaround them.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
