[Monotone-devel] some (negative) feedback -- useful reading

[Nathaniel Smith]

Some people aren't happy:
  http://thread.gmane.org/gmane.comp.handhelds.openembedded/8657

Some points:
  -- they want initial pull fixed
  -- apparently netsync incompatibilities are causing real users
     problems.  Unfortunately we probably need to do one more
     data-migration to switch cert formats, and I'd guess at least two
     more netsync breaks (once to make it fast, once to sit down and
     seriously clean it up and come up with a story for compatibility,
     so we can have some confidence we'll be able to support it)
  -- monotone-dumb would be useful.  Since it wouldn't take much more
     than a few days of python hacking to make it basically usable,
     this seems doable if anyone wants to make it happen.  (I'm not
     quite sure this 

I don't know what "disapprove, true merges are hard" means.  I don't
know what "phil does not have send a key" means.  (Who is Phil? :-))

I also don't know what "our database got corrupted" means.  Since we
tend to put "don't corrupt data" somewhere above "have functionality"
on the priority list, this makes me really concerned.  Does anyone
have details here?  (I know there have been instances where bugs
allowed history to go a bit cross-eyed -- is that all?  I don't tend
to think of it as "data corruption" _exactly_, since all data is
recoverable, and we do in fact recover it when you migrate forward,
but... I can see how it would be a problem for people.  So far
0.26pre1 has only had 1 history-handling bug uncovered, and it was
probably the most minor bug I've ever seen, so this makes me hopeful
that these are behind us.  Unfortunately, saying "we don't have these
bugs like these anymore" is not a statement that can be made until
more people have banged on things.

Does anyone know what they mean by git having cherrypicking?  I assume
this must be just the equivalent of a nice wrapper around diff+patch?
(I guess we could add the same thing in a few minutes, since Timothy
wrote the sideways/backwards update code last night, and the
algorithms are completely identical for update and basic
cherrypatching (without all the cool parts of real cherrypicking, but
also the only thing that anyone knows how to implement).  Maybe the UI
would just be, take two revs in history, and apply the change between
them to the current working copy?)

OpenEmbedded people: I'd very much like to hear any more details on
what's going on here, how we can help, if it would be useful to talk
to anyone or provide more details, etc.  Let me know!

-- Nathaniel

-- 
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield