Re: [Monotone-devel] Some more issues

[Nathaniel Smith]

On Mon, Feb 14, 2005 at 11:07:10AM -0500, Jeremy Fincher wrote:
> Here are some more issues I've noticed while doing some 
> research/working with monotone...
> 
> 1. The project page on Savannah has many open items that seem to be 
> resolved, but are still open.  Many other items seem to apply to much 
> older versions of Monotone (I saw at least one for 0.12).  If there's 
> anything I can do to help close some of these items, I'll be happy to 
> help out; the bug list needs to be short if anyone's to trust Monotone 
> with their source code.  I'm interested in helping Monotone wherever I 
> can, and I think reducing the number of open items on Savannah is some 
> low-hanging fruit I could help with.

Unfortunately, de facto, that bug tracker is not used.  This has a lot
to do with Graydon being historically the only person who can actually
close bugs (because savannah has really weird permissions, or
something, I don't really understand why this is true), so it doesn't
get maintained at all.

I've been pushing towards a model where we use the test suite as a bug
tracker; it has some limitations occasionally, but it does work pretty
well, and is what we are in fact using right now.

I just got administrator permissions on the tracker, though; if anyone
can figure out what knob I have to twiddle so other people can close
bugs, then I'm happy to do so :-).

> 2. I couldn't sync with the official monotone server; the process 
> seemed to hang (sucking up 100% CPU) after revision 1566.  I did a 
> ktrace on it (I'm using OSX) and it seemed that it was repeatedly 
> calling select with a timeout of around a second; I'm not sure why that 
> would peg the CPU, but it was doing that.

Syncing using what version?  Are you sure it was really stuck?  (It
has to think for a while after its received all revisions, in order to
figure out what files it needs to get to go with them.)

> 3. Graydon mentioned a packet format in #monotone; I got a small taste 
> of that when adding the official key for the monotone repository.  Is 
> there any documentation as to the format of these packets, or, at 
> least, is there a way for me to generate these packets for arbitrary 
> "database things" like revisions and certs so I can reverse-engineer 
> the format?  I think this interface will be satisfactory for my attempt 
> at implementing the "better than file granularity" selector for 
> patches.

I think a satisfactory interface for that would be to parse the output
of 'monotone diff', then let people pick some of the hunks, then check
out into a temporary directory, apply those hunks, and commit from
there.  Then update to the resulting revision, I guess.  This is
actually not _that_ unreasonable an interface, and it's definitely
something that could be made effective with not too much coding.

There is no documentation on the format of those packets, and you're
basically reimplementing big hunks of monotone if you want to generate
your own -- putting things into the right format isn't so hard, but
figuring out the data you'd want to put into them is much worse.

-- Nathaniel

-- 
When the flush of a new-born sun fell first on Eden's green and gold,
Our father Adam sat under the Tree and scratched with a stick in the mould;
And the first rude sketch that the world had seen was joy to his mighty heart,
Till the Devil whispered behind the leaves, "It's pretty, but is it Art?"
  -- The Conundrum of the Workshops, Rudyard Kipling