Hi, all, i'm just kind of thinking out loud here and am looking for other's ideas on this topic...
Porting fossil(1) to fossil(3) has taught me a _lot_ about how fossil really works (i've always just hacked on its outer edges until this undertaking). One of the things i learned, which i should have deduced earlier but didn't, is how the timeline is generated. First a bit of context, so that what follows is clearer... At its core fossil uses something called a "control artifact" to record all changes. Sometimes they're called a manifest, though a manifest is just one form of control artifact. A CA is a formal record of a change (any sort of change) in a fossil data store, and is 100% independent of sqlite. Their structure is described in detail at ( http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki), but you do NOT need to read/understand that page in order to follow/participate in this discussion. When fossil reads a manifest, e.g. during a local commit or a sync, it "crosslinks" that manifest, updating data and relationships in other tables. One step of this crosslinking process is the updating of the timeline view. The timeline is created locally for each repo and is not part of the sync process (i just learned that a couple days ago). This, in principal, allows an application to update the timeline however it wants to based on manifest data. In principal only, not in practice, because the updating of the timeline is done at such a level that it would be pretty difficult for a client to hook into that (it would be impossible in the current app). But not impossible at the library library. The current fossil(3) code indeed hard-codes the strings/descriptions used in the timeline (because copy/paste is an easy way to port the code ;), but it "would be possible" for a client application to register a callback which gets called during the crosslinking process, allowing the client to take over updating of the timeline or do any other sort of post-processing he'd like to do. So... supposing the library _could_ do that (yes, it "could," but "should it?" is another question entirely), what are the types of things people would _want_ to do with it? The options which immediately come to mind include: a) Generate the timeline output in a custom format. e.g. do not use links (or use links which work in your app). b) write it in your native language. c) Skip updating of the timeline altogether for embedded applications where there is nobody to read it, or to save a small bit of space. d) Incremental data mining - collecting stats about artifacts incrementally as new manifests are parsed. A rebuild will (if i'm not mistaken, but i might be) end up triggering a crosslink of all manifests in the history of the project. e) No, crosslinking is not be a good place to implement post-change/commit triggers because on a rebuild you'd end up spamming the world with commit mails. What else? The ideas you provide may help shape what this functionality looks like. :-? -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
