-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roan Kattouw wrote:
- -- Update type: Modify, Add, Delete, Rename
- cp_action enum ('M','A','D','R'),
Does rename even exist in SVN? Correct me if I'm wrong, but I always thought SVN implemented renaming as a combination of copy and delete.
Looks like I was making shit up and guessed wrong -- it's actually "replace".
http://us.php.net/manual/en/function.svn-log.php
Speaking about copy, do you have a way to store and display stuff like (Copied from foo) for added files?
SVN's log and diff output are pretty "dumb" by default for moves and show an entire-file removal followed by an entire-file creation.
One could probably detect these cases and show something nicer.
+-- And for our commenting system... +-- To specify follow-up relationships... +CREATE TABLE /*$wgDBprefix*/code_relations (
- cf_repo_id int not null,
- -- -> cr_id
- cf_from int not null,
- -- -> cr_id
- cf_to int not null,
- primary key (cf_repo_id, cf_from, cf_to)
+) /*$wgDBTableOptions*/;
Why didn't you just add cr_prev and cr_next to code_revisions?
Because that would be totally insufficient. How many of your code changes only relate to *one* revision before them and *one* after them? I know a lot of mine have many, many more relations. Take this example case:
* r100 introduces a bug * r200 makes a broken fix for the bug in r100 * r201 tweaks r200, which fixes r100 * r202 tweaks r200/201, which fixes r100 * r230 reverts r200, r201, r202 (which fix r100) cause it breaks something else * r285 restores the r200/r201/r202 fix for r100, but with additional fixes so it's right
A single "prev" and "next" don't really indicate the relationships to which other revs you want to look at.
Also, the cf_ prefix is kind of a weird choice here, since there's no 'f' in code_relations.
Um, it might have made since at some point. ;)
+-- Freetext tagging for revisions +CREATE TABLE /*$wgDBprefix*/code_tags (
What exactly are these tags going to do? Native support for marking as reviewed or reverted would be nice.
A few possible tags off the top of my head:
reviewed, reverted, sucks, awesome, cleanup, i18n, fixme, backport, branchpoint, suspicious, revertme, funny, blogme, major, feature, regression, bc, compat, wtf
Also, the only indices on this table are (ct_repo_id, ct_rev_id, ct_tag) and (ct_repo_id, ct_tag, ct_rev_id). Wouldn't (ct_tag, ct_repo_id, ct_rev_id) be useful too (e.g. for finding all revisions in all repos with a certain tag)?
Prolly good, yes. :)
- -- Wikitext blob of the comment.
- -- FIXME: Consider using standard text store?
- cc_text blob,
Does 'standard' text store mean the text table or the external disk thingy? I would recommend using the same class that stores revision text, so this extension doesn't have to worry about whether external storage is enabled or not.
Right, that's what encapsulation is for. ;)
These comments, unlike page text, though are generally going to be smallish and won't have multiple revisions -- so no batch gzip/diff benefits.
- -- Timestamps of threaded parent and self to present a
- -- convenient threaded sort order:
- -- "20080130123456"
- -- "20080130123456,20080230123456"
- -- "20080430123456"
- --
- -- Allows 17 levels of nesting before we hit the length limit.
- -- Could redo more compactly to get 31 or 63 levels.
- cc_sortkey varbinary(255),
Nice one. What will happen when the limit is hit, though?
Well, sorting breaks. :) Probably would want to have it just not let you add child replies beyond the arbitrary depth limit (boo-hoo).
You might wanna add a cr_review field holding the sum of all these cc_review's to the code_rev table, along with an index. With that, the review sum will always be correct even if not all comments are displayed, and it'll be possible to search for e.g. all revisions with a negative review sum.
Considered it, haven't bothered yet. ;)
About the extension as a whole: are new revisions added to the system the second they're made, or are they imported on a regular basis? Also, it would be nice to have some kind of e-mail notification feature (either through the wiki's e-mail system or through a mailing list).
There are a few possibilities: * check for new revs on-demand * periodic cron check * use a notification event to trigger a check for updates (like existing IRC and mail notifications)
A post-commit hook in SVN could easily ping the wiki to go grab the latest revisions, for instance.
- -- brion