Re: [Monotone-devel] [sqlite] disk locality (and delta storage)

[Nathaniel Smith]

On Fri, Feb 10, 2006 at 07:06:27PM -0500, address@hidden wrote:
> Daniel Carosone <address@hidden> wrote:
> > Wiki pages doesn't seem so hard, they're pretty much text documents
> > stored in a VCS anyway. 
> 
> There are some complications.  Each wiki page acts if it where
> its own independent project or branch.  And then you probably want
> some way see all current leaves and to do merges from the web
> interface.  
>
> If you intend your system to be publically accessible, then
> you will also need some mechanism to delete (or at least 
> permanently hide from public view) the spam that miscreants
> occasionally post on wiki pages and sometimes also on tickets.
> Some kind of "death cert" perhaps.

These all seem reasonably straightforward; basically just UI issues.

The trickiest bit is the making each page independent bit... but you
can just do that by having each page be a single file named "page.txt"
in its own branch.  Alternatively, sometimes it is very nice to allow
renaming in a wiki.  (I have definitely wanted this feature, when I
realized that the spec I have been working out on a wiki page actually
should be called something different than what it currently is.)  You
can allow this pretty straightforwardly even in the distributed wiki
case if you just use monotone's rename support...

> > Bug tracking state would require a little
> > more smarts, with suitable text formats stored in the VCS and
> > code/hooks to assist in making sane merges between multiple heads of a
> > given ticket, but even that doesn't seem terribly hard.
> 
> My thinking about tickets is that each change to a ticket
> is just a small, signed, immutable record (like a cert)
> that contains a variable number of name/value pairs.  The
> names are things like "title", "description", "status",
> "assigned-to", etc.  To reconstruct the current state of
> a ticket, you sort all the pieces by their creation time
> (their actual creation time, not the time they happened to
> arrive at your database) and read through them one by one.
> Values overwrite prior values with the same name.  So
> in the end, you have one value for each field name - and
> that is the current state of your ticket.

You seem to be reinventing history tracking with certs.

It seems a lot simpler to just make tickets, like, a text file, and
then use the existing history tracking tools.  They're quite tuned and
involve some non-obvious bits.  In particular, compared to this
scheme, they're insensitive to clock skew, they provide real merging
(in your scheme, if I change a field locally, and you change the same
field locally, then whichever of us has our clock set later at that
time will silently clobber the other person), and users can
investigate the history of a ticket using normal history browsing
tools...

> It is also very useful to have certs that record a link 
> between a revision and a ticket.  In this way you can record 
> that a bug was introduced by, or fixed by, a particular 
> revision.  The linkage between tickets and revisions has 
> proven to be particularly valuable in CVSTrac.

Indeed!  Enabling this kind of workflow integration is _exactly_ why
we have this generic cert thing built in.  No-one's done much with it
yet, though, so really we don't even know how far the possibilities go
-- so I get all excited when someone does :-).

> Once you have cross linking between revisions and tickets,
> if you add a google-like search you then have a very powerful
> system for doing source tree archeological work.  This comes
> up a lot in maintaining SQLite.  Somebody on the web reports
> a problem.  I have some vague memory of fixing a similar
> problem 9 months ago, but do not recall where it was or how
> I fixed it.  By using the search feature of CVSTrac together
> with the links between tickets and check-in comments, I can
> quickly find the historical problem and pinpoint exactly when
> and how the problem was fixed.  Then post a URL to the specific
> ticket that described the problem and the specific revision that
> fixed it.

Yep!  Monotone has much more structured information than CVS, and it's
much easier to get at; one can get at all sorts of things.  You can
track not just the list of commits, but things like branches, figure
out whether they're merged or not yet, see which branches work is
occurring on...

Or how about another cool use of certs:
  http://mt.xaraya.com/com.xaraya.core/index.psp


I think the move from CVS to systems with simpler, saner data models
opens up huge opportunities for better visualization, data mining,
data navigation, community awareness, workflow management... sadly, I
never get to work on this, because I end up spending my time trying to
make the basic pieces just work :-).  But I can't wait to see what
other people come up with, and can cheer loudly while they do...

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco