On May 11, 2016, at 4:39 PM, Marko Käning <sec001+fos...@posteo.net> wrote: > > On 12 May 2016, at 00:26 , Warren Young <w...@etr-usa.com> wrote: > >> I volunteer you. :) > > Oh. I never had a look inside Fossil so far…
Fossil’s code is uncommonly well structured and fairly straightforward to follow. The worst I can say about the code is that it is often overly terse and sparsely commented. But, the clear high-level organization means you can usually find out where the problem code is, which is at least half the battle. For example, each comamnd’s implementation starts off in src/foo.c for “fossil foo”. If the code goes deeper than that, your text editor’s cross-referencing ability (e.g. ctags for vi) is usually sufficient to trace things from there. Occasionally while chasing problems in the source I’ve had to escape that level of organization because the actual problem is below it, which often requires understanding how the data is stored in the various Fossil DBs. At that point, you want to read docs like this one http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki and those it links to. > I hope some more proficient with > its code might step in here. :) You’re holding a gift from the programming gods right there in your hands: a project you care about. The biggest obstacle to becoming proficient in a given code base is not having a good reason to dive in. If you dive in without a project in mind, you just sort of wallow around ignorantly on the surface. With a project in hand, though, you cut through most of the irrelevancies. You can see what matters and what doesn’t. You don’t become expert in the whole code base that way, but you do gain expertise in that one area. Along the way, you might find something else to attack. Repeat until expert. :) _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
