monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: usher and roaster? [was Re: [Monotone-devel] Merging cvssync in smal


From: Larry Hastings
Subject: Re: usher and roaster? [was Re: [Monotone-devel] Merging cvssync in small pieces: Pipe abstraction]
Date: Tue, 11 Oct 2005 05:42:49 -0700
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Jon Bright wrote:
Zbynek Winkler wrote:
I also remember reading about some "roasters"...?
"rosters"... though I've also no clue what they are.

I've been hanging out in the #monotone IRC channel, and believe I have a basic theoretical understanding of "rosters", which I will now trot out.  If there are any factual errors in the following, I hope someone will correct me.

The following definition was run by Graydon, who gave it his stamp of approval:
A "roster" is a local-only data structure that contains cached information about a particular revision/manifest, optimized to make many operations more correct and much faster.
It's not a change the underlying model/paradigm, but it is a restructuring of how monotone works with that data internally. "manifests" and "revisions" are much the same as before, and are still how revision information is exchanged between databases; "rosters" are never sent over the wire, they are always built and maintained locally.


The rosters branch touches nearly every internal data structure, so one will have to perform an explicit data migration when upgrading to monotone with rosters.  (I believe the first attempt at such a migration happened earlier late Monday night!)  I can name a couple of data structural changes right off the bat:
  1. The ".mt-attrs" hack to store file attributes is gone, they now have a way of storing attributes internally to monotone.
  2. A directory is now represented explicitly, whereas currently in monotone (as with Perforce) it is an implicit part of the path to a file.
  3. The format of "manifest" is now basic_io.
  4. Files and directories are now assigned a "local identifier", which identifies neither the name nor the contents of the file, but rather its "essence".  It is this identifier that lets you rename and change a file in a single revision, yet track it back to its previous revisions.  (The "local identifier" is an local-only optimization, as the external representation is rich enough to allow you to track such changes.)

The one-sentence "elevator pitch" for rosters: Any time you ask about some problem in #monotone, either graydon or njs says "oh, yeah--that's fixed with rosters".


larry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]