At 06:10 AM 7/31/2010, Joshua Paine wrote: >On 07/31/2010 08:09 AM, Dig412 wrote: >> Are you planning on releasing the code? This could be really >> useful for development shops to run on their own servers to >> manage projects. > .... > If you've got the server access and know-how to install James' > app, then surely you can write a 2-line CGI script and drop all > your .fossil files in an arbitrary directory. ....
The 2-line cgi script isn't the interesting part. The interesting part is the surrounding management interface that provides a web face for creating and cloning new repositories and otherwise managing the repositories themselves. IMHO, there really is a value add to that, but it also isn't the sort of thing that belongs inside of the fossil executable. After all, SourceForge, GitHub and their ilk are successful because providing the right amount of administrative capability over and above the hosted repository makes them useful to people. I've taken a similar approach myself. I've been working on a package I've been calling Museum (where else do you find fossils?) which is consists of native builds of fossil and thttpd to run in a D-Link DNS-323 NAS box. My plan is to eventually share this with any interested parties, but it is still in a pre-alpha works-for-me kind of state at the moment. Its primary use case in my shop is to provide a self-contained set of clones of my project work. It needs a web face because the DNS-323 doesn't naturally provide a console of any sort, or even a telnet server. None of the CGI scripting is particularly innovative or even complicated, other than the goal of requiring as few new ARM executables as possible both because cross-compilation adds its own joys, and because there is only a limited amount of room available in the RAM disk that its linux boots from. > If someone built a repo management tool that could manage users > across multiple repos and/or do ticket or timeline aggregation, > that would be helpful for us "development shops". That is another piece of integration that is also outside the scope of the fossil executable. But it certainly would be valuable to be able to group several related repositories together in some kind of a unified view. There is a lot to work out about how that would work in practice, of course. Can you create a new ticket in that view? Move it from repo to repo? Copy it? Refer to it in wiki/comment text from a different repo? Clone the unified view as if it were a single repo? If anyone is interested in my toy Museum, contact me on or off list and I will happily push things from pre-alpha to alpha. Perhaps I should just clone it to chiselapp.com and let the interested parties have at it? Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
