26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
-
+
+
|
<h2>"Rules" for Code Contributors</h2>
* All code contributors must have a license waiver on file with DRH, as the hope is to eventually release this code as the next generation of Fossil. Non-code contributions are happily accepted from anyone.
* When working on bits which themselves write to the repository, e.g. creating checkins, please be exceedingly careful not to corrupt the db :-D.
* Please try to conform to the overall coding style (as laid out by Fossil v1).
* Don't bother using branches unless you really want to - the trunk has no stability guarantees and is very much in flux, so feel free to work there instead of a branch.
There is nothing holy or sacred about this repo, so feel free to hack at will. Generally the quickest/most complete way to test changes it to add them to the th1ish script bindings (in <tt>[/finfo?name=th1ish/shell_extend.c|shell_extend.c]</tt>). If you prefer writing C-level tests, please add them to <tt>test.c</tt> in the top-level directory or to a new test app if you like. See <tt>FossilApp.c</tt> for a mini-framework to bootstrap new test apps.
There is nothing holy or sacred about this repo, so feel free to hack at will. Generally the quickest/most complete way to test changes it to add them to the th1ish script bindings (in <tt>[/finfo?name=th1ish/shell_extend.c|shell_extend.c]</tt>). If you prefer writing C-level tests, please add them to <tt>test.c</tt> in the top-level directory or to a new test app if you like. See <tt>FossilApp.c</tt> for a mini-framework to bootstrap new test apps and [f-tools] for examples which take that approach.
<h2>News</h2>
Notable changes (newest at the top)...
* 20130816: <b>Milestone:</b> manifest parsing is more or less complete, covering the whole range of control artifact types. Strict validation is done (including the Z-card hash) to ensure that bogus manifests cannot be read. "Parsing," in this context means converting a raw Fossil manifest to a higher-level (OO) construct. That construct can then be output to a new manifest which is identical to the old one <em>except</em> that there are some caveats involving sub-hundredths-of-a-second precision loss in the round-trip timestamp conversion (but such round-trip manifests are useful only for testing/proof-of-concept, and are not needed in practice).
* 20130815: the past couple days have seen many incremental additions to the manifest machinery. We can now "round-trip" some artifact types, parsing them into a high-level form and re-generating them from that high-level form.
* 20130812: Started the [f-tools].
* 20130811: Got "manifest crosslinking" of control artifact (tag changes) ported in.
* 20130810: <b>Milestone:</b> the library [/info/70666e1c11|saved its first tag] today! (The timestamp of the tag was intentionally falsified for testing purposes.)
* 20130808: Restructured source tree and ported build configuration process to [http://msteveb.github.io/autosetup/|autosetup] (because that's what Fossil uses). Existing build files (not the sources) still require GNU Make on a Unix platform, though. Many thanks to Steve Bennett (autosetup's author) for his assistance.
* 20130804: ported in the symbol-to-uuid resolution bits from the main repo. These are what allow apps to use short-form UUIDs and symbolic names like "trunk," instead of having to use 40-byte UUIDs everywhere.
* 20130803: most of the infrastructure for creating [http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki|manifests and control artifacts] is in place, but we don't yet write them to the db.
|