On Sun, Feb 05, 2012 at 01:36:20PM +0100, Jeroen Hellingman wrote:
Quite an odd-beast, but why not consider fossil?
(http://fossil-scm.org/index.html/doc/trunk/www/index.wiki)
Stand-alone, integrates everything, and could be used on a book-by-book base...
There are some super features in that package. I never looked at it before. Some shortcomings/drawbacks I noted: - filenames are lost, so we'd need an additional layer to map updated files into the collection our readers see and download from (fossil names all files by hashes, and mixes "source" with wiki, bug tracking, etc.) - single maintainer, seems like (though with some additional contributors, and an opening for us to join as contributors), putting some risk of abandonment - user control seems simplistic, and possibly not amenable to the hierarchy/meritrocracy approach to "who can commit". A challenge that many such solutions will have for us is whether to treat each book as a "project," or the whole collection. I am leaning towards each book as a project, but that only works if we can easily share/inherit from existing books. That is, nobody is going to use a Web UI to set up 38K projects to "seed" our efforts. Anyway, this does look good, but I saw some limitations. -- Greg
On 2012-02-05 09:56, Greg Newby wrote:
I'm still pursuing the theme of an existing sophisticated code base to enable supporting multiple versions & formats of our eBooks (user-contributed, curated, edited, masters and revisions).