Outgoing InterTrac links _from_ a CVSTrac install can be accomplished with custom markup, as in:

{quote:%x}

which would be referenced via something like:

{quote:{<markup>: ticket:451 #451}} {quote:{trac: wiki:InterTrac InterTrac}}

This means we need to allow generic RSS substitutions in the header. To that end, we add %R for the URL and %F for the title (a distinct feed needs a distinct title).

Figuring out whether a page has its own RSS feed is done by looking for an "RSS" entry in the action bar. The title is built from the project name and the current page title.

Then, to override the default (timeline) RSS feed on any given page, it's just a matter of doing something like:

common_add_action_item(mprintf("tkthistory.rss?tn=%d",tn), "RSS");

and the header output logic will just pick it up. (check-in: c72535f17c user: cpb tags: trunk)

In order to allow it to work in both normal web browsing and the encoding needed for RSS (where we _need_ to encode even entities), I modified htmlize (%h) to take an "allow entities" flag, and added a new %R formatting option which disables this flag. %R is used by the RSS formatter to do the final content generation. This means anywhere wiki content is allowed someone can write é and, apparently, it works.

Keep in mind that I don't normally use anything except ASCII in my day-to-day environment, so someone who cares about this stuff should maybe test it out a bit more than myself. (check-in: 14e235cdd5 user: cpb tags: trunk)

Only one left in the table stuff in /cvstrac/view.c (check-in: f18b4a5e70 user: cpb tags: trunk)

Basically, when a user starts editting a ticket (or appending a remark), the last "changetime" is embedded in the form. At submit time, CVSTrac checks to ensure that changetime is still good and refuses to proceed. The user still has all the change visible and can copy them elsewhere, but can't "finish" the change. A "force" checkbox might be useful here?

By default, this is disabled. (check-in: 6e09701d50 user: cpb tags: trunk)

tags inside forms * changing hspace into margin * changing wrap="type" into class wraptype (this may be problematic) * adding DocType ... still we got Content-Type missing and warning with lists +

at Wiki

*: entity tag is a =quoted-string=, and hence needs quotes *: Vary:* SHOULD be included when dealing with server-negotiated responses (check-in: 74510a0008 user: cpb tags: trunk)

*: This should catch both "NULL" descriptions and zero-length strings. *: Additionally, tighten up the setup page to always remove the old description before changing anything and check the new description before setting anything. (check-in: 163a463930 user: cpb tags: trunk)

Break the two separate conditions into separate <form> areas and loosen up the condition which create the setup_user link. (check-in: d25d699321 user: cpb tags: trunk)

CVSTrac doesn't really have a way to track proper merges (which basically implies multiple CHNG.prevvers entries) but we _can_ reference merge source check-ins in the commit message. It's still not as easy as I'd like to follow GIT development, but this makes it clearer what things are merges and what commits are being pulled into the merge.

*: we need to ingest the whole commit tree as we check refs, and we need to do it such that roots get the lowest CN numbers and are databased before anything which relies on them. This means making =git_ingest_commit_tree()= truly recursive. *: drop the temporary =ci= table, since we now need to do it all in one pass *: add a function to convert multiple parents into a merge list and update the check-in comment with something like "Merged [n1], [n2], ..." *: in order to _display_ merges, we need to use =git-diff= rather than =git-diff-tree=. *: add =pxHistoryReconstructPrep= and =pxHistoryRescanPrep= callbacks to =g.scm= so we can "do things" to SCM-specific tables and whatnot before a history reconstruct or rescan. In the case of GIT, a reconstruct requires removing all the refs milestones. Other SCMs may have similar requirements.

This doesn't break database compatibility, but you _will_ have to do a reconstruct if you want to see merges properly. Unfortunately, a reconstruct may alter check-in numbers and break links in wiki text or manually created ticket cross-references. (check-in: 3219fa7f89 user: cpb tags: trunk)

The fix is to detect the missing FILECHNG records and ensure we create the refs milestone anyways. Once we've got the refs milestone with an proper object reference, we'll never try to update those refs again. (check-in: 7e9b7e50b0 user: cpb tags: trunk)

Basically, we drop the TAGS and HEADS tables entirely and exploit the fact that GIT doesn't make _any_ use of the CHNG.branch and CHNG.directory fields. CHNG.branch is meaningless since branches aren't static and a single commit might belong to any number of branches. CHNG.directory is also meaningless because GIT operates on the entire tree in a single commit. So for GIT milestones, CHNG.branch=refs/* and CHNG.directory=object.

This allows us to completely drop a couple tables (which may break reports) and simplifies a lot of queries and stuff. Because we've got other places to put things, the milestone message can also be shortened.

To upgrade an existing database, something like:

DROP TABLE heads; DROP TABLE tags; DELETE FROM chng WHERE milestone>0 AND message LIKE '%(%, commit %';

before any GIT history update will be fine.

As an added bonus, we're no longer looking directly at files in the GIT repository. We just use command-line tools. So we're probably a lot more resiliant to changes in repository layouts. (check-in: 89dfc6a081 user: cpb tags: trunk)

Use another temp table to help prune the list down to the bare minimum. There's room for other improvements, too. (check-in: a00e3770a4 user: cpb tags: trunk)

The obvious and 100% compatible fix would be something like this:

--- format.c 30 Sep 2006 11:01:30 -0000 1.91 +++ format.c 28 Jan 2007 21:33:13 -0000 @@ -1323,8 +1323,9 @@ || (sMarkup.lenType==11 && strncmp(sMarkup.zType,"rightreport",11)==0) || (sMarkup.lenType==10 && strncmp(sMarkup.zType,"leftreport",10)==0) ){ - char *zCaption = mprintf("%.*s", sMarkup.lenArgs, sMarkup.zArgs); + char *zCaption, *zCaptionOrig; char *zAlign = 0; + zCaptionOrig = zCaption = mprintf("%.*s", sMarkup.lenArgs, sMarkup.zArgs); if( sMarkup.lenType==11 ){ zAlign = "align=\"right\""; }else if( sMarkup.lenType==10 ){ @@ -1335,7 +1336,7 @@ embed_view( atoi(sMarkup.zKey), (sMarkup.zArgs==sMarkup.zKey) ? "" : zCaption, zAlign ); - free(zCaption); + free(zCaptionOrig); zText += sMarkup.lenTotal; i = 0; wordStart = lineStart = paraStart = 0;

But the whitespace skipping never can happen as the is_markup() call around the parsing code already skipped all leading whitespaces. Hence we fix the deallocation problem by just removing the unnecessary second whitespace skipping attempt. (check-in: 72db38160a user: rse tags: trunk)

Currently, we're using the authorizer to enforce restrictions on report statements. Since, internally, CVSTrac distinguishes between query and execute styles of commands, it makes some sense to add similar authorizer facilities to some of these functions as well.

This patch introduces the concept of an authorizer stack to which we can push and pop from (otherwise, interactions between query and the existing report authorizer are impossible to manage) and uses it in all the query-style functions. As a side-effect we also need to create a separate =db_execute_callback()= function. A define, USE_STRICT_AUTHORIZER, is created to "help" CVSTrac developers avoid using the from query/execute call.

The goals are multiple: to defang potential SQL injections, inadvertant data leaks, and (eventually) privledge escalations such as are currently blocked in reports. Eventually, it may also get used to help enforce protections should we implement embedded scripting. It also introduces a framework for preventing silly mistakes (i.e. CREATE/DROP table outside of schema and history updates, deleting rather than updating things, etc). (check-in: 41fc1c9f55 user: cpb tags: trunk)

common_.c:399: warning: the address of 'azLink' will always evaluate as 'true' common_.c:415: warning: the address of 'azAction' will always evaluate as 'true'

..for the following code lines...

[...] if( nLink && azLink ){ [...] if( nAction && azAction ){ [...]

...as we have...

static const char *azLink[50]; static const char *azAction[50];

...and ISO-C always implicitly makes the name of the array variable to be a pointer to the array and as the array is a static array it _always_ is a valid pointer and hence always "true" in boolean context.

OTOH we don't need the comparison here at all as the nLink and nAction check is really sufficient to know whether the array contain content. So, remove the warning by removing the useless parts from the boolean expression. (check-in: ad7cff7f48 user: rse tags: trunk)

*: Loosely based on {link:http://www.cvstrac.org/cvstrac/attach_get/195/setup_diffs.tar.gz setup_diffs.tar.gz}, *: create =cgi_wikitext= and =cgi_textarea= function to control output *: =cgi_wikitext= allows the caller to determine _relative_ height compared to the configured _maximum_. For example, a short wiki text area might be 20% of the maxmimum height. *: /setup_interface allows the wiki area width and maximum height to be specified. (check-in: 4d30fc6114 user: cpb tags: trunk)

The conversion to CSS isn't complete, but it's functional and I'm having some trouble getting much further with it at the moment.

So rather than try to develop two trees in parallel it's easier (for me) to merge it back to HEAD, fix some other functional problems that are _really_ bothering me, and finish the CSS migration at a more leisurely pace. Not the most ideal situation, but we'll just have to work with it... (check-in: 1727797fd7 user: cpb tags: trunk)

For distribution, it's not reasonable to expect a separate stylesheet file to ship with the binary. It's also necessary for the original version to be available to admins who want to revert or study the original.

*: create a =makecss.c= program to turn /cvstrac/cvstrac.css into =css.c= *: =css.c= implements two web pages: /cvstrac.css and /cvstrac_default.css *: /cvstrac.css returns the latest /cvstrac.css attached to /setup_style. Failing that (i.e. doesn't exist), it falls back to /cvstrac_default.css *: /cvstrac_default.css always outputs the original build-time stylesheet. *: /setup_style mentions this *: default header now references =cvstrac.css= and (why not) =cvstrac_default.css= as an alternate. (Leaf check-in: f98c06e463 user: cpb tags: css-patches)

Tested with as many configs as possible, but this could break configurations which do substantial URL aliasing/rewriting. (check-in: 73fd5657bc user: cpb tags: trunk)

*: two things are covered: wiki markup and the page header *: wiki markup is fairly straightforward. Mostly the addition of class or id tags plus a bit of code cleanup to facilitate it. The *bold* markup got the biggest beating, I'd say. *: the page header... The main problem there is faithfully reproducing the table-driven layout, which basically turned into adding a couple extra wrapper

Basically, we create a structure under =struct Global= which contains SCM "capabilities", callbacks, etc. The inidividual SCM's export a single =init_<scm>= function to fill the structure. Then everything interacts solely with that structure rather than having "if this, else that" behaviour all over the place.

At least, that's the idea. There's still a lot of CVS-isms... (check-in: 2ab24f0240 user: cpb tags: trunk)

*: Introduced =cgi_input_elem()= to handel all <input> elements we use. *: Wrapper functions around =cgi_input_elem()= for each element type. *: Changed =*_fieldset()= so it wraps all elements in <fieldset> only if title is present. *: Replaced all <input> elements with calls to new functions in /timeline. (check-in: 97d1f3508a user: chorlya tags: trunk)

*: Wrap navigation bar and action bar in <map> *: Group timeline options in <fieldset> (check-in: ee4125fbc9 user: chorlya tags: trunk)

*: having a [Help] button on pages with a corresponsing wiki page *: a link to CvstracDocumentation on the /index *: a beefed up wikiinit.c (run =cvstrac wikiinit ?dir? ?project?= to pick this up).

Admin documentation is still woefully incomplete. (check-in: 57a6cbfdb4 user: cpb tags: trunk)

*: user documentation largely complete, if a bit terse in places. Admin docs are mostly incomplete. *: Fixed most of the documentation to correspond to the current state of HEAD. I hope. *: [Help] link no longer shown if target wiki page is missing (Leaf check-in: 8acd235c71 user: cpb tags: manual-patches)

sqlite3 <project.db> create table old_tool AS select * from tool; drop table tool; UPDATE config SET value='2.0' WHERE name='schema'; cvstrac update <?dir?> <?project?> sqlite3 <project.db> REPLACE INTO tool SELECT * FROM old_tool; drop table old_tool;

*: do a schema upgrade which adds a _lastfn_ field to FILE. *: update repository modules to ensure that _lastcn_ is up-to-date *: simplify the living daylights out of the /dirview query (check-in: 252362e49b user: cpb tags: trunk)

*: don't generate nearly as many directories. More like 500 rather than 3000. This tightens up the tree and increases the number of revisions per given file, which is really what we want for testing. *: fix a bug which created checkins with no files. *: setup password should be initialized to "setup", since we're supposed to start as a 1.0 schema (i.e. plain text passwords). (check-in: a1b353b298 user: cpb tags: trunk)

make maketestdb ./maketestdb project ./cvstrac update `pwd` project ./cvstrac server 8008 `pwd` project

Obviously, there's no content for the repository. The DummyTrac approach would still be best for that... (check-in: e7fe0a4149 user: cpb tags: trunk)

In a nutshell, we create the *wiki()*, *tkt()* and *chng()* functions. Each causes whatever it wraps to be displayed as the given type. So a checkin could be displayed as a link using something like:

chng(cn) AS 'Checkin'

While you could show a checkin comment, without the underscore formatting, using something like:

wiki(substr(message,0,140)) AS 'Comment'

This, obviously, is all backwards compatible with existing report formats.

Also, prevent recursion caused by embedded reports being triggered from wiki markup and, of course, document this stuff. (check-in: 005083d288 user: cpb tags: trunk)

*: support both local and bare GIT repositories. The repository root is now defined as wherever the git files exist, either =/path/to/project/.git= for local repositories or =/path/to/project.git= for bare repos. *: make =insert_file()= use the =db_exists()= call. Less ambiguity there... *: fix the recursive =git_ingest_commit_tree()= to only do recursive when we actually encounter multi-parent commits. Most of the time, we just loop. Otherwise, importing extremely active projects will just blow the stack (when the commit chain hits around 600 items on my memory-starved system). *: ensure there's a "HEAD" file in the configured repository. Just a sanity check. We don't actually use it for anything, but gitweb does it too. (check-in: 748ec80be1 user: cpb tags: trunk)

1: adjust the throttler counter up. Currently, we adjust up by half the limit. This means the second attempt will exceed limits if the attempt is made too quickly.

2: clear the captcha cookie. This forces the user to go through a second captcha test. (check-in: 9ce181118c user: cpb tags: trunk)

*: remove blob.c... the =blob_decode()= function is the only part of that we'll need anymore and that can be a static function in /cvstrac/db.c *: introduce a schema 2.0 change which decodes all attachments and saves them as blobs. *: change the attachment retrieval to use a callback query in order to extract the blob. The regular =db_query()= call can't handle embedded NUL's. (check-in: 2c3987e9d3 user: cpb tags: trunk)

This is going to break compatibility, so I definitely need to write some sort of CvstracUpgrading page.

What we've got here is a straight conversion from the SQLite 2 API to the SQLite 3 equivalent. No other fancy stuff is attempted such as handling UTF-8 and such. We're also not doing any changes to schemas or queries. (check-in: a510997d4c user: cpb tags: trunk)

*: define a =g.zLinkURL= which prefixes all relative links output from the wiki formatter. Normally, this would be =NULL=. *: create a =format_link()= function in /cvstrac/format.c to turn handle formatting of links and prefixing with =g.zLinkURL=. So far, only links generated from wiki formatting need this treatment. *: change /cvstrac/rss.c to actually set the link URL (to =g.zBaseURL=, obviously). (check-in: ab144ece6e user: cpb tags: trunk)

SELECT sdate(-invtime) AS 'When', who AS 'By', ipaddr AS 'At' FROM wiki WHERE name=cgi('p') ORDER BY invtime

*: expanded the results structure for the standard query callback to count the number of columns in the results. *: created a common =db_err()= function *: =f_option()= now includes the column counts in the output *: the first column of the first row is always the default value. Users can adjust the default by changing the ordering of the query results *: if two columns are returned, the second column is considered the "description" while the first is the value. This allows for things like:

WHERE assignedto=option('User',"select id,name from user")

*: call notify when attachments are added (%h substitution) *: provide substibutions for ticket change row ids to prevent races *: update /setup_chng page (check-in: 5fce617094 user: cpb tags: trunk)

This is useful for a bunch of reasons:

*: being an HTTP/1.0 construct it's more widely support than entity tags. *: it allows us to check for a cache hit _before_ we actually generate any content. In the case of /getfile, _before_ we do an expensive =popen()= to snarf the contents from the repository. *: one of the side-effects of [613] is to add a constantly changing timestamp to the RSS output; this defeats the content-based hashing ETag scheme that we're using. (check-in: c5a5a1d61d user: cpb tags: trunk)

*: include a <pubDate> tag with every item *: include <pubData> and, optionally, <lastBuildData> tags in the header *: output a *Lat-Modified* HTTP header if we've got a build date *: variable RSS TTL now available (check-in: b7ccc28072 user: cpb tags: trunk)

*: create a /dirview option which does a long/detail view of a directory. This shows age, user, revision and the last commit message for each file with links to all the appropriate CVSTrac pages. *: add an option for the admin to specify the default browse style (long or short). Defaults to short. *: add a cookie so the users last browse style is retained during navigation. *: add a _default_browse_url()_ function to figure out what's best and uses it anywhere a "dir" browse link is used. This gives the user a consistent browse experience. *: tighten up the /setup_interface layout a bit (check-in: 0c985d8d79 user: cpb tags: trunk)

SELECT * FROM ticket WHERE owner=option('User','SELECT id FROM user') OR assignedto=option('User')

SELECT tn FROM ticket WHERE owner=option('User','SELECT id FROM user')

Which pretty much works as expected.

Also added *aux* and *option* documentation to /rptedit and /rptnew pages. (check-in: dc9694754b user: cpb tags: trunk)

*: /setup_header page now more general /setup_style *: added option to restore the style from the default *: add a %B (base URL) substitution, so we can generate URL's like "%B/cvstrac.css". *: adds the ability to attach files to the setup_style page by basically saying that ticket zero (which isn't a valid ticket number) is that page. This is a little hackish, but it means that the administrator has a "private" attachment playground for all the various files that need to be uploaded. *: maps URLs of the form http://<cvstrac path>/<filename> to ticket zero attachments, by name, meaning that stylesheet elements don't need to guess at things like attachment numbers and stuff. To add a logo, for example, you can just use . If the same filename exists multiple times, the most recent attachment is chosen. *: handles/hacks around the constant/expiry/caching issues for #522. (check-in: 19b0579463 user: cpb tags: trunk)

*: minor fix to cookie lifetime handling *: clicking "Show Timeline" will save settings to a cookie and viewing the timeline will extract the settings and apply them. This can always be overridden. *: add a /setup_timeline to handle this and, eventually, some RSS 2.0 options. (check-in: 3816c38267 user: cpb tags: trunk)

*: output from /attach_get always includes a *Last-Modified* header. We should modify this to handle the *If-Modified-Since* condition, too. *: Output of specific versions of /getfile (which generates the raw file contents) is flagged as being "constant" since it'll never change. We don't really do anything with the constant flag at the moment, but we should look at using expiry. Unfortunately, the stuff that's often flagged as constant really isn't that constant. *: when generating CGI replies, calculate an entity tag using the MD5 hash on the buffer. This is included in all responses as the *ETag* header. *: additionally, when we generate the *ETag* we also check it against the *If-None-Matches* request header and, if it's there, we're about to return a 304 response without sending the contents. Even though we still have to _generate_ the page content, sending a 300 byte rather than 100k /timeline is still a rather large bandwidth savings. This also works _invisibly_ with _every_ page we generate, including attachments, RSS output, etc. *: drop the *Pragma: no-cache* and replace it with a bit of cache control. *Pragma: no-cache* wasn't really doing much because there wasn't any other cache control headers that would have confused a cache into thinking that it could actually keep the stuff anyways. For cache control, all we really need to do is distinguish between public and private data (i.e. anon vs logged in users). *: remove the response header stuff from =main.c=. Everything else like that was already being done in =cgi_reply()= anyways... (check-in: aceb64f982 user: cpb tags: trunk)

*: restrict *access_load* to setup users *: anonymous users can't see contact information *: RdWiki permission to read wiki. Mind you, you also need that to see reports in the first place, but... *: Checkout permission to read *chng*, *filechng* and *file* *: Read permission to see *ticket* columns (check-in: 9242e11819 user: cpb tags: trunk)

*: create a =common_add_help_item()= function which takes a wiki page as an argument and ensures that a *Help* link to that page goes somewhere appropriate. Currently, "appropriate" is defined as the navigation menu.

*: ensure that every page which does something "interesting" has one of these help items.

*: add a "Help" item to the main index page.

*: start writing some content for this manual. This is going to be slow going, to say the least, but I've identified which pages need to be written and started on a few, including the main manual page, the admin page, the ticket page, and the check-in page. Others will follow... (check-in: 5de1e153b9 user: cpb tags: manual-patches)

 tags. If it's detected to be HTML, it'll be passed through unchanged. This
logic was being duplicated in a bunch of places.
*: =common_dumpfile()= handles all the permutations of getfile filtering and the
bRaw flag to implement the basic logic needed to output a particular version of a
file. SCM's just fill in the function needed in a =popen()= call to write the file
to stdout.

*: use INSERT's for the FILECHNG records, not REPLACE. *: need to extract the date from the committer record, not the author. Otherwise... Well, cg-update on cogito just blew the ordering all to bits. *: make sure some buffers are properly zeroed. (check-in: e24ed98434 user: cpb tags: trunk)

*: add a Cancel button to the /tktundo action bar (check-in: 33a862021a user: cpb tags: trunk)

As it turns out, you can't count on just the .git/refs/heads references to build an accurate picture of the revision tree. For example, my test case {link: http://www.kernel.org/git/?p=cogito/cogito.git;a=summary cogito} seems to have commits under the tags references that don't appear in a tree from either of the heads. Not sure why this is, but the gist of it is that we need to treat tags as heads for the purposes of building a full commit tree.

This patch cleans up a lot of stuff so we can actually make that work. And it does, although importing {link: http://www.kernel.org/git/?p=cogito/cogito.git;a=summary cogito} is now around 6 minutes rather than 2.5. There's probably some SQLite optimizations that could be done there...

One interesting consequence is that tags and heads are automatically turned into milestones, which means the timeline always has, as the latest entry, a milestone for every head. Based on my understanding of git development patterns, that not entirely a Bad Thing. (check-in: 8dd6510a6b user: cpb tags: trunk)

Also, don't display Patchset or Inspection if the user doesn't have the permissions to use them. (check-in: a1d1317770 user: cpb tags: trunk)

*: log messages now variable length. This works nicely for Subversion because it actually indicates length before the message *: tree copies and deletes now handled sanely *: fixed some memory management issues in the patch *: skip =svn_did_repository_change()= check if historysize reset to zero. *: assorted other minor changes and optimizations. (check-in: 787797f694 user: cpb tags: trunk)

*: It works against a _git_ working directory, but it's not ready for production use *: file diffs aren't implemented because, oddly enough, there doesn't seem to be anything like _git-diff-blob_. Something to fix, I guess. *: documentation to follow. To try it out:

make APPNAME=gittrac ./gittrac init </path/to/working/directory> <project> ./gittrac server 8008 </path/to/working/directory> <project> login as setup/setup, change repository to /path/to/working/directory go to timeline

*: break out of the search loop sooner. That knocks about 15% off the schema upgrade time with my setup (50000 filechng records, many branches, manual changes to revision numbers). (check-in: 53ab03fc06 user: cpb tags: trunk)

*: add a =g.zSCMName= field to the global structure and initialize it to the human-readable name of the SCM. i.e. "CVS" or "Subversion". *: adjust various pages (except, notably, the user/passwd stuff) to be less CVS-specific or to have non-CVS options, depending on what's appropriate. This includes outputting %s(g.zSCMName) and using less specific terms (i.e. "repository" rather than "CVSROOT/history file"). (check-in: a3f0967227 user: cpb tags: trunk)

Note that because the ticket history has moved to a separate /tkthistory page (#378) the diff only runs when people actually explicitly want to see histories. But even without that, the decrease in ticket history sizes would still be a win since CPU time is usually cheaper than bandwidth. (check-in: 423c0f6d9f user: cpb tags: trunk)

*: define a =get_filefilter()= to setup a pipeline for optional filtering. This handles the filename and version substitutions. *: change =*_dump_version()= to use a filter if available. *: add a setup for the filter to /setup_diff. In the process, update it to make sense for SvnTrac (#459). (check-in: 62a8b886dd user: cpb tags: trunk)

 tags.

*: add a "raw" flag to =dump_version()= so we can still use it for regular /getfile
retrieval.
*: change =cvs_dump_version()= and =svn_dump_version()= to try to do something
useful with the flag. This is where a filter would be used.
*: add a /fileview URL as the default browse file display. It has, of course, the
option to display the "raw" bits. A useful side effect is that file display is
faster in Konqueror and other browsers which handle HTML better than straight
"text/plain".
*: /fileview will inline known image formats into the page.
*: /getfile still works as expected.

*: add %u (user) and %c (capabilities) substitutions *: alter how the markup substitution function works to make it much easier (i.e. two lines) to add new substitutions. (check-in: 49da6cee57 user: cpb tags: trunk)

make all APPNAME='svntrac'

*: This updates the schema to 1.8, adding the _prevvers_ and _chngtype_ fields to the _filechng_ table.

*: change _cvs_previous_version()_ to check the _prevvers_ field rather than just making assumptions about things. This is _much_ nicer.

*: the hairy part is found in _db.c_ in the _db_upgrade_schema_8()_ function. In a nutshell, we want to take what we know about the old _filechng_ tables and populate the _prevvers_ and _chngtype_ fields. *Be warned* that I haven't tested this on a repository with weird version number increments. (check-in: 76a751e4c1 user: cpb tags: svntrac-patches)

The CVS version still hasn't been as well tested as I'd like. The patch _looks_ good, but how it applies is a different story. (check-in: a364e9365b user: cpb tags: svntrac-patches)

make svntrac

*Note* that this is all in the _svntrac-patches_ branch.

*: a set of common function calls goes in =history.c= which can be dispatched to whatever SCM subsystem is approriate. *: anything that deals directory with the CVS repository (including the =history= file and the genuine ,v files is abstracted behind this API. Nothing else sees files, just filenames in the database. *: added some additional error handling so the content side of things can gracefully handles failures in the repository access code. *: moved =xref_checkin_comment= to =db.c= (check-in: 570734ddde user: cpb tags: svntrac-patches)

*: a block is a markup which handles all contents in between {quote:{markup}} and {quote:{endmarkup}}. Only one definition is needed. The contents of the block are in the %b substitution.

*: terminology change. Straight markups are called "Markups" or "Program Markups". Blocks are called "Blocks" or "Program Blocks". The latter is basically just an external filter.

*: Created a pipe_block() function to handle the filtering stuff. It also includes the previous external program functionality. Some of the guts were stolen from the path in #353 at http://the.taoofmac.com/cgi-bin/cvs/chngview?cn=86 (check-in: 686ac5053f user: cpb tags: trunk)

*: export ndigit() and is_eow() functions from format.c *: make xref_checkin_comment() use them (check-in: f5e0052566 user: cpb tags: trunk)

This obviously doesn't handle the case where someone wants to have unbalanced {'s or }'s in a markup. In that case, using the HTML character entities { and } (wrapped in <HTM L> and </HT ML> markup) should work. (check-in: 34e2d62fe6 user: cpb tags: trunk)

*: %x is useful to implement markups where the arguments provide "optional" descriptions. For example, {quote:{getfile: filename} would produce a link like {link: filename filename} while {quote:{getfile: filename description}} would produce something like {link: filename description} using one formatter, {quote: %x}.

*: %r is useful for program formatters which need to know where to find the sqlite database (along with the %n substitution, of course). (check-in: 0d9ec65118 user: cpb tags: trunk)

Cyclic redirection in /wiki/test/login?nxp=/wiki/test/login%3Fnxp%3D/wiki/test/test

Or whatever the URL is. This handily blocks all the various unauthenticated user login cycles as well as the getfile/blah/blah/blah.c cycle. There might be a more elegant solution, but I can't think of it. (check-in: 4e3e21d60d user: cpb tags: trunk)

*: add a special {quote: {markups}} markup which outputs the descriptions for the available list of custom rules. This sort of thing is useful for FormattingWikiPages where we need to be able to list the server-specific rules.

*: in order to do custom markups we need to do argument substitutions. markup_substitution is a function which takes a custom markup format, does the argument substitution, and feeds back the string for further processing.

*: in the case of "internal" rules, that just means the substituted string is dumped into the output. This allows for simple markups like, say, {quote: {sqlitetkt 56}} which would be written as {quote: #%k}.

*: in the case of "program" rules, we run an external script with the arguments on the command line. This is somewhat similar to the ticket notification and custom diff programs.

*: finally, the append_formatting_hints() function gets some logic to list the custom rules. (check-in: e6b1053812 user: cpb tags: trunk)

This does introduce a problem... When we get a new tag, we want to delete any older versions of that tag. However, existing databases won't have the directory to search on so we end up deleting any global instances of the tag. This maintains the semantics of the older database, but it's a bit annoying. Newer milestones, of course, will only be deleted if the directory matches too. (check-in: b5d5927499 user: cpb tags: trunk)

*: "revision" should be ignored when we've already got a valid revision. *: "date:" should be ignored when we've already got a time (you could also check zUser, among other things). (check-in: a037e14dde user: cpb tags: trunk)

*: when a client exceeds the throttle limit, they're punted to a captcha page. If they get punted to the page more than CAPTCHA_LOCKOUT times, the normal throttle blocking kicks in.

*: a client can hit the /captcha page as many times as they want. This might be a problem, but we don't penalize human users who might generate a lot of hits.

*: Once the user gets passed the captcha page, they get a cookie which disables the throttle behaviour. A logged-in user is also immune. (check-in: e73fc99f96 user: cpb tags: trunk)

*: add a captcha counter to the access_load table. This is necessary since we can't count on the client to keep state in a form or URL.

*: (for #390) add a directory field to the chng table. This is necessary to differentiate between rtags in different modules

*: (for #380) add a description field to the attachment table (check-in: bce7e39a77 user: cpb tags: trunk)

*: link titles mean larger timeline HTML. On my test box, larger seems to range anywhere from 10% to 30%.

*: link titles mean a db lookup for every generated link. Again, non-trivial numbers on an active timeline.

*: check-in link titles are nowhere near as useful as ticket link titles since most places that show ticket links (timeline, tktview, tkthistory) also contain considerable check-in context. Specifically the same thing as in the link title. Wouldn't be a bad idea to add check-in summary info (i.e. some metric indicating the size or number of files). Of course, this would be less useful to anon users, so you'd probably only want to enable it for logged in users.

Also, the setup_interface page looks much more useful with more options... (check-in: 213e5aca28 user: cpb tags: trunk)

navigation is defined as links that take you to somewhere unrelated to the current page. Actions apply, somehow, to the current page.

*: common_standard_menu is defined to be navigation items only since there's no "default" action. *: rename common_replace_menu_item to common_replace_nav_item. We don't need a corresponding call for actions since there's no defaults to replace. *: rename common_add_menu_item to common_add_nav_item. This call changes the azLink/nLink variables. *: create a new common_add_action_item which handles the azAction/nAction variables. *: modify common_vlink_header to create a separate row with BG4 background for the action items. *: change everywhere that calls any of the common_add/common_replace calls to either a navigation or action item. I _think_ I got them all correct. *: change the "Add a new inspection..." link to be an action item. (check-in: c1c4d08724 user: cpb tags: trunk)

*: remove the ticket_change_history() function *: in the /tktview page, add a History link to /tkthistory *: implement the /tkthistory page, a combined chronological view of all ticket changes, related checkins, attachments, inspections, derivations, and whatever else we can think of (check-in: 069349d92b user: cpb tags: trunk)

The rule is: *: logged in users always have g.okInfoLink=1. *: anon users get the config option infolink *: if the infolink flag isn't in the database, anon users have g.okInfoLink=0. (check-in: 07c0523342 user: cpb tags: trunk)

markup within html.

Also added a report of the total execution time to the logfile output and fixed a commenting error. (check-in: 2cdb08793b user: drh tags: trunk)