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

[Holger Freyther]

Nathaniel Smith <njs <at> pobox.com> writes:

> 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? )

First of all I think monotone is of create quality. I have not seen
many Free Software projects that uses invariants all over the place.
Also the usage of lua makes it feel more professional and more mature
than other distributed systems (e.g. git, darcs).


Phil  is Phil Blundell of arm, binutils, debian, gpe, glibc, linux, OpenEmbedded
fame and he has not contributed to oe after the switch to monotone.
I don't want to speak for him but I think it was due the early netsync
incompabilitiy and slow initial pulling.
And as you may see by his contributions it is a great loss for any project
he is not contributing to.


> 
> 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 have used tailor to convert from monotone to other SCM's. On the conversion
I hit the following issues:
    - mt-attrs claims a non existant file executable.
    - renaming of files lead to error when the directory already existed.

This is what I described as 'corruption' as I was unable to checout.
As a workaround I had to lessen some invariants.
I think the history and data itself is not corrupted. If you are interested
I could start tailor again and give you the problematic revisions (other
scm's do not even notice such 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?)

I can not comment on the actual implementation but the idea is. You have
created a branch for stabilisation (e.g. org.openembedded.oz354fam083)
and in the main development branch (e.g. org.openembedded.dev) you have
pushed some bug fixes. So what one wants is to propagate the revision
with the bugfix to the stabilisation branch.
Currently we manually diff+patch the bugfixes to the oz354fam083 but
this leaves us in a situation we do not know which changes were merged
into the oz354fam083 branch as the manual merging can not be tracked
that easily. I do not know if this is in the scope of any scm... but it would
be nice to have.
(http://bugs.treke.net/show_bug.cgi?id=350)



> 
> 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!
I will ask Richard Purdie to comment on his issues when he tried to discard
a couple os revisions but he described it as very hard. I can not comment
on it as I have never done it.




The main issue I think we as the OpenEmbedded project face are:
    - speed when pulling. 400 revs I pulled yesterday to my machine took 
       a couple of hours.
    - speed when pulling.
    - forcing our users to upgrade to new monotone versions when distributions
       do not ship packages yet.

What would be nice to have:
    - fast readonly co of the current head (could be done using rsync as wel)
    - monotone copy file new_name
       as this is what happens quite often in OE. Let us say we have a recipe 
for
       monotone 0.30 and now 0.31 is released and we want people to build
       both. We would copy the version 30 to 31 and maybe do some updates
       (updating MD5SUM and SHA256).


kind regards
   holger