Brion Vibber schreef:
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.
Right, I forgot the fact that you can have complex trees with nodes (revisions) having multiple parents and multiple children.
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
Basically, these tags can be divided into two categories: tags that link the revision to other revisions, and those that don't. This got me thinking about merging the code_relations and code_tags tables for the first kind of tags.
To clarify using your earlier example: * r100 needs to be fixed (fixme tag) * r200 fixes (fix tag) r100 (parent) and r100 was fixed (fixed tag) in r200 (child) * r201 tweaks (cleanup tag) r200 (parent), and r200 was cleaned up (cleanedup tag) in r201 (child) * r202 tweaks (cleanup tag) r200 and r201 (parents), and r200 and r201 were cleaned up (cleanedup tag) in r202 (child) * r230 reverts (revert tag) r200, r201 and r202 (parents), and r200, r201 and r202 were reverted (reverted tag) in r230 (child) * r285 reverts (revert tag) r230 (parent) and r230 was reverted (reverted tag) in r285 * r285 fixes (fix tag) r100, r200, r201 and r202 (parents), and r100, r200, r201 and r202 were fixed (fixed tag) in r285
This calls for a table that defines not only parent-child relationships, but also the nature of those relationships (using tags). That table could look like:
CREATE TABLE code_relations ( -- Key to repo_id rel_repo_id INT NOT NULL,
-- Key to cr_id rel_from INT NOT NULL,
-- Key to cr_id -- NULL for single tags without a parent-child relationship rel_to INT NULL,
-- Tag that applies to this relationship rel_tag VARBINARY(255) NOT NULL,
PRIMARY KEY(rel_repo_id, rel_from, rel_to, rel_tag), KEY rel_to(rel_repo_id, rel_to, rel_from, rel_tag), KEY rel_repotag(rel_repo_id, rel_tag, rel_from, rel_to), KEY rel_tag(rel_tag, rel_repo_id, rel_from, rel_to) );
(Come to think of it: you might wanna name your indices so they can be FORCE INDEXed if necessary.)
In this case, the rows would look like (assuming repo_id=0): (0, 100, NULL, 'fixme'), (0, 100, 200, 'fixed'), (0, 200, 100, 'fix'), ... (0, 230, 285, 'reverted'), (0, 285, 230, 'revert'), (0, 285, 100, 'fix'), ... (0, 285, 202, 'fix'), (0, 100, 285, 'fixed'), ... (0, 202, 285, 'fixed')
These comments, unlike page text, though are generally going to be smallish and won't have multiple revisions -- so no batch gzip/diff benefits.
True.
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).
That's what I was thinking. It's not ideal, but if the depth limit is high enough (the 17 you mentioned is probably enough), a limit violation probably won't happen too often. Also, you can't really blame the software for not allowing you to add an 18th-level comment: since you're probably gonna put deeper-nested comments further to the right, such comments would look horribly ugly anyway (I don't even wanna think about what 64 levels would look like), and 17 is already quite a lot of comments for one revision. Such large discussions probably shouldn't take place on CodeReview, but on wikitech-l or BugZilla.
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.
I was personally thinking about the third option, since that's how the existing notifications work.
Roan Kattouw (Catrope)