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)