My wishlist: 1. Full-text search through the file contents and history. Search this list for "howto `grep' through old revisions" to see some ideas (mine is at the end of that thread), but some other ideas could work great, too. 2. Partial pulls - I mean that if pulling from a large repository, and the pull is aborted partway, whatever artifacts (or deltas) were already pulled and stored in the repo should remain, instead of being rolled back. I think this wouldn't even be too hard in the current fossil, just a matter of moving a couple of commit statements around.
On Sun, Jul 21, 2013 at 10:15 PM, Stephan Beal <sgb...@googlemail.com>wrote: > On Sun, Jul 21, 2013 at 7:12 PM, Eduardo Morras <emorr...@yahoo.es> wrote: > >> a) Creation of graphs to show statistics. >> >> I'm on it now, writing a minimal png with 32bit ARGB color and a >> minimal graph lib. >> > > Added to the list. > > >> b) Plugins and hooks c modules >> >> I use fossil with a central fossil repository from/to where individuals >> sync. Some module examples: >> > > Added to the list. > > >> a) when a user sync/merge to trunk in central server, it compile/test >> the code, after receive but before merge, and if compile/test fails reject >> sync/merge. >> b) project management features, global gant graphs, percentage of work >> done, >> c) source code parser, to find where a function, macro, etc... is >> declared >> d) fts of documentation >> > > If we don't want to write such hooks in C (which might not be practical) > then a a scripting engine is implied. IMO the right choice, given fossil's > history, would be TCL, but any option we choose brings with it long-term > dependencies or maintenance (if we embed a small interpreter like jimtcl or > lua). To me jimtcl would be the obvious candidate, but i was told at some > point that it has too many incompatibilities with standard TCL to be of > interest to the harder-code TCLers. > > > >> d) extend user capabilities >> >> Some superuser can own/lock some files in central repository or at >> least, in trunk. For example makefiles, binary files, project >> configuration, etc... >> > > i was thinking about that as well, but IMO the current system works > remarkably well. It effectively offers up to 26 (or 52) roles, which is far > more than projects of fossil's scale need. We could perhaps add a mechanism > to allow clients to add letters to the permissions alphabet. Or toss out > the mechanism and do something new. i think a full-fledged role management > system would be way overkill, but if we're starting from scratch anyway... > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
