I suppose I could file a ticket requesting this, but I'd like to discuss it first as I feel odd about filing tickets for feature requests that may not be desirable.
I have a Fossil-hosted project at http://spielproject.info. In this instance, the project owns the entire domain, and I'd like for the URLs to reflect that, which they currently do. However, Spiel has spun off a few subprojects, which I'd like hosted in their own repositories and with their own websites. I'd like to host these on spielproject.info at URLs like http://spielproject.info/bazaar, http://spielproject.info/accessibility-helper, etc. First, I know that I can accomplish this via web server configuration and rewrites, so please don't take this in that direction. When Fossil is pointed to a directory rather than a repository, I'm wondering if anyone else would find it useful to serve up index.fossil as the project that is automatically selected if none is given? So URLs like: http://spielproject.info/wiki?name=faq would automatically load the given page in index.fossil, while: http://spielproject.info/bazaar/wiki?name=faq would load the page with the same name in the bazaar repository? This would also simplify configuration some. I currently have two distinct Fossil configurations, one which points to a directory of all my various projects hosted at http://dev.thewordnerd.info, and others pointing to distinct repository names hosted at various TLDs. With support for index.fossil, I'd only need the directory case pointing at different directories. TLDs could just replace the index.fossil, and are then free to spin off subprojects in different repositories simply by dropping in another fossil. Note that this would preclude you from naming projects wiki, timeline and other reserved words for the directory case with an index.fossil present. Those seem like such specific cases that I don't think they'll be encountered often enough. Does this seem like a good idea, or does it make Fossil too complicated? Again, I know I can do this with web server configuration, but I like the fact that I can just drop in a fossil and have it served up by the CGI/server instance, and supporting this case would seem to simplify that setup even further. Thanks for reading. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users