Monotone issues

Monotone issues

[Richard Purdie]

Just so everyone is aware, it became apparent that a newer version of
strace in OE.dev had disappeared. This was traced back to something from
tmbinc which shouldn't have been merged but accidentally was.

A disapprove wouldn't work since the automerger had merged it. I asked
the monotone devs for advice on irc and was told I should be able to
suspend that revision and work from and older one.

I ran:

mtn suspend 50d03f17a42a3854cd87f47ef75084da297d194e

and then 

mtn up -r e651c4fa9a5d1fc6120cc2309e9cba1388cecc52

and then committed something to form a new head revision.

This appeared to work for me locally, I pushed it, pulled on another
machine and all seemed well, it would only affect anyone who'd actually
checked out the bad revision (50d03f17a42a3854cd87f47ef75084da297d194e)
who would then need to run 
mtn up -r11d1a9e6662c57de089d25a6900d5325f85d282e
and we ran the risk of someone merging this again but it could be worse.

monotone 0.37 wouldn't show the other head but I suspect older monotones
do and don't support the suspend certificate. I suspect the automerger
runs on a machine with an older monotone since it then merged the
problematic head back and put us back to square one.

So I've applied a reverse diff to restore the broken files and damaged
the history :(. I was thinking it was a larger scale problem than it is,
only about 12 files were affected. Its amazingly hard to work this out
though.

The difficulty in fixing this simple problem along with the speed issues
make me wonder if monotone is right for the future though? I do get put
off making commits due to the lack of speed too...

Richard

Monotone issues

[Richard Purdie]

Just so everyone is aware, it became apparent that a newer version of
strace in OE.dev had disappeared. This was traced back to something from
tmbinc which shouldn't have been merged but accidentally was.

A disapprove wouldn't work since the automerger had merged it. I asked
the monotone devs for advice on irc and was told I should be able to
suspend that revision and work from and older one.

I ran:

mtn suspend 50d03f17a42a3854cd87f47ef75084da297d194e

and then 

mtn up -r e651c4fa9a5d1fc6120cc2309e9cba1388cecc52

and then committed something to form a new head revision.

This appeared to work for me locally, I pushed it, pulled on another
machine and all seemed well, it would only affect anyone who'd actually
checked out the bad revision (50d03f17a42a3854cd87f47ef75084da297d194e)
who would then need to run 
mtn up -r11d1a9e6662c57de089d25a6900d5325f85d282e
and we ran the risk of someone merging this again but it could be worse.

monotone 0.37 wouldn't show the other head but I suspect older monotones
do and don't support the suspend certificate. I suspect the automerger
runs on a machine with an older monotone since it then merged the
problematic head back and put us back to square one.

So I've applied a reverse diff to restore the broken files and damaged
the history :(. I was thinking it was a larger scale problem than it is,
only about 12 files were affected. Its amazingly hard to work this out
though.

The difficulty in fixing this simple problem along with the speed issues
make me wonder if monotone is right for the future though? I do get put
off making commits due to the lack of speed too...

Richard

Re: Monotone issues

[Graeme Gregory]

On Thu, 31 Jan 2008 23:51:39 +0000
Richard Purdie <rpurdie@rpsys.net> wrote:
> The difficulty in fixing this simple problem along with the speed
> issues make me wonder if monotone is right for the future though? I
> do get put off making commits due to the lack of speed too...
> 
Sounds like it is time for our regular re-assessment of the use
of monotone. Maybe we should start another round of testing other
SCM systems again. I know your not the only person seeing mtn start
to creak.

Graeme

Re: Monotone issues

[Michael 'Mickey' Lauer]

On Sunday 03 February 2008 22:03:53 Graeme Gregory wrote:
> On Thu, 31 Jan 2008 23:51:39 +0000
>
> Richard Purdie <rpurdie@rpsys.net> wrote:
> > The difficulty in fixing this simple problem along with the speed
> > issues make me wonder if monotone is right for the future though? I
> > do get put off making commits due to the lack of speed too...

Agreed. It's starting to be unbearable again.

> Sounds like it is time for our regular re-assessment of the use
> of monotone. Maybe we should start another round of testing other
> SCM systems again.

Agreed. To add up on that, last month Graydon Hoare officially announced his 
retiring from the monotone project. Not that this would have any short term 
effect, but it adds up to general feeling of re-evaluation.

Ideally, we would collect candidates and experience reports pretty soon and 
make a decision at or shortly after the next OE meeting (FOSDEM).

-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Monotone issues

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael 'Mickey' Lauer schreef:
| On Sunday 03 February 2008 22:03:53 Graeme Gregory wrote:
|> On Thu, 31 Jan 2008 23:51:39 +0000
|>
|> Richard Purdie <rpurdie@rpsys.net> wrote:
|>> The difficulty in fixing this simple problem along with the speed
|>> issues make me wonder if monotone is right for the future though? I
|>> do get put off making commits due to the lack of speed too...
|
| Agreed. It's starting to be unbearable again.
|
|> Sounds like it is time for our regular re-assessment of the use
|> of monotone. Maybe we should start another round of testing other
|> SCM systems again.
|
| Agreed. To add up on that, last month Graydon Hoare officially
announced his
| retiring from the monotone project. Not that this would have any short
term
| effect, but it adds up to general feeling of re-evaluation.

Since this all was triggered by a bad commit, we should evaluate commit
and review policy as well and ideally end up with something that can be
hooked up to http://review-board.org/.

| Ideally, we would collect candidates and experience reports pretty
soon and
| make a decision at or shortly after the next OE meeting (FOSDEM).

After, since at least 3 core developers won't be at FOSDEM.

regards,

Koen


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHps1TMkyGM64RGpERAj6NAJ9Q2hFba+aVBro12iBnV0PWUh1S0gCeNxd5
AQWY1x22VXHYj1yuBt+WjeU=
=Uyow
-----END PGP SIGNATURE-----

Re: Monotone issues

[Florian Boor]

Hi,

Graeme Gregory schrieb:
> Sounds like it is time for our regular re-assessment of the use
> of monotone. Maybe we should start another round of testing other
> SCM systems again. I know your not the only person seeing mtn start
> to creak.

I agree... I have never been a friend of monotone but got used to it. But it
reminds you that it is still not ready for complex projects. Just to mention the
pain that updates are not atomic operations and problems during an update end up
in the pain of a broken repository.
Another major problem is that a monotone update sometimes causes a very time
consuming database update. Waiting half a day on a really fast machine for the
database to become usable again is a real showstopper.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Monotone issues

[Rod Whitby]

> Graeme Gregory schrieb:
>> Sounds like it is time for our regular re-assessment of the use
>> of monotone. Maybe we should start another round of testing other
>> SCM systems again.

Let's just cut to the chase and discuss why we're not using git ...

-- Rod (who started using git recently to push kernel patches upstream)

Re: Monotone issues

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rod Whitby schreef:
|> Graeme Gregory schrieb:
|>> Sounds like it is time for our regular re-assessment of the use
|>> of monotone. Maybe we should start another round of testing other
|>> SCM systems again.
|
| Let's just cut to the chase and discuss why we're not using git ...

1) git couldn't import the flat-file OE tree, neither could cogito
2) git 1.4 just threw away your local changes on what git calls a 'merge'
3) it has no sense of 'time' inside commits
4) it is lossy
5) it has no guarantee against man-in-the-middle or filesystem corruption.
6) You can't attach attributes (e.g. QA results) to revisions
7) You can't store empty directories in git (ask Holger about the pain)

To expand on 5: Monotone uses rsa to ensure two things:

1) the tree is uncorrupted (in the sense of bad disks)
2) the tree is trusted

With git you say 'my tree has 6767e' and I say 'my tree has 9090d' and
we have no idea of what went wrong or where it went wrong, just that our
trees don't match.

To expand on 4:

Git was designed to cater people that send each other patches over a
mailinglist that rot for a few weeks till a new 'merge window' opens,
the current tree is basically thrown away and you have to put your
patches on top of a new release.

That is why we didn't use git in the past, things could be very
different now.

And we all have to keep in mind that OE is the odd one out in the SCM
worlds, since we have about 25 small commits per day on files that have
a really short lifetime, not 1 change per week to main.c. This is one of
the reasons why monotone is so slow for us.

regards,

Koen

- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHpt+IMkyGM64RGpERAsDVAKCOrlpxiTzFtejCzGugXH46fP3PYACgnYnC
GPIwcaUXvaClKDVDb5GGLog=
=K0S+
-----END PGP SIGNATURE-----

Re: Monotone issues

[Graeme Gregory]

On Mon, 04 Feb 2008 19:42:06 +1030
Rod Whitby <rod@whitby.id.au> wrote:

> > Graeme Gregory schrieb:
> >> Sounds like it is time for our regular re-assessment of the use
> >> of monotone. Maybe we should start another round of testing other
> >> SCM systems again.
> 
> Let's just cut to the chase and discuss why we're not using git ...
> 
Well something I wondered about in my sleep is can zecke's mtn->git
script work both ways. Then we don't have to change SCM in one
nasty leap. We can run both in parallel for a while and when the
traffic on mtn ceases (if it does) terminate that.

Graeme

Re: Monotone issues

[Rod Whitby]

Koen Kooi wrote:
> Rod Whitby schreef:
> |> Graeme Gregory schrieb:
> |>> Sounds like it is time for our regular re-assessment of the use
> |>> of monotone. Maybe we should start another round of testing other
> |>> SCM systems again.
> |
> | Let's just cut to the chase and discuss why we're not using git ...
> 
> 1) git couldn't import the flat-file OE tree, neither could cogito

I wonder if it can now ...

> 2) git 1.4 just threw away your local changes on what git calls a 'merge'

Different tool, different cheat-sheet to learn.  That's always to be
expected when changing tools.  Monotone merges are so bad that I flatly
refuse to even attempt a manual merge, preferring to blow away my whole
monotone repository and start again rather than try a monotone manual merge.

> 3) it has no sense of 'time' inside commits

Can you expand on this one?

> 4) it is lossy

See below.

> 5) it has no guarantee against man-in-the-middle or filesystem corruption.

That's an interesting one.  My understanding of git was that if you had
the same hash as someone else for the same tagged version, then you were
guaranteed to have the same filesystem contents.

> 6) You can't attach attributes (e.g. QA results) to revisions

Have we ever done that in OE?

> 7) You can't store empty directories in git (ask Holger about the pain)

Some might call that a good feature :-)  Do we use empty directories in OE?

> To expand on 5: Monotone uses rsa to ensure two things:
> 
> 1) the tree is uncorrupted (in the sense of bad disks)
> 2) the tree is trusted
> 
> With git you say 'my tree has 6767e' and I say 'my tree has 9090d' and
> we have no idea of what went wrong or where it went wrong, just that our
> trees don't match.

I would have thought you just compare git logs from the last tag to see
where they diverge.

> To expand on 4:
> 
> Git was designed to cater people that send each other patches over a
> mailinglist that rot for a few weeks till a new 'merge window' opens,
> the current tree is basically thrown away and you have to put your
> patches on top of a new release.

Hmm - on the linux kernel lists you mainly see pull requests these days.

In any case, can you describe why you think the tool is lossy, as
opposed to commenting on a specific linux kernel development workflow
(which doesn't need to be propagated exactly to OE) ?

> That is why we didn't use git in the past, things could be very
> different now.

I tried git a year ago, and had some frustrations.  I tried it again
last week, and had no frustrations.  Either it, or I, have got better at
doing things.

Then again, I have no problems with monotone these days either, cause my
Makefile does things repeatable and correctly for me ;-)  I just type
"make update" and go watch some TV while monotone does it's thing.  Then
I start development ...

-- Rod

Re: Monotone issues

[Graeme Gregory]

On Mon, 04 Feb 2008 20:54:35 +1030
Rod Whitby <rod@whitby.id.au> wrote:
> > 2) git 1.4 just threw away your local changes on what git calls a
> > 'merge'
> 
> Different tool, different cheat-sheet to learn.  That's always to be
> expected when changing tools.  Monotone merges are so bad that I
> flatly refuse to even attempt a manual merge, preferring to blow away
> my whole monotone repository and start again rather than try a
> monotone manual merge.
> 
This was a bug with git 1.4, totally denied by git developers, but
magically fixed with git 1.5

At least that was my experience of this, I havent seen it since I
started to use git 1.5 and reports on the net dried off after this
point as well.

G

Re: Monotone issues

[Michael Krelin]

>>
> Well something I wondered about in my sleep is can zecke's mtn->git
> script work both ways. Then we don't have to change SCM in one
> nasty leap. We can run both in parallel for a while and when the
> traffic on mtn ceases (if it does) terminate that.
> 

I think this sounds like an option. As I grew frustrated with monotone I
was going to develop tool like that (akin to git-svn) a while ago, but I
only more or less got mtn->git direction to work which also preserves
mtn revisions in comments and then got distracted by other things...

Love,
H

Re: Monotone issues

[Paul Sokolovsky]

Hello,

On Mon, 04 Feb 2008 19:42:06 +1030
Rod Whitby <rod@whitby.id.au> wrote:

> > Graeme Gregory schrieb:
> >> Sounds like it is time for our regular re-assessment of the use
> >> of monotone. Maybe we should start another round of testing other
> >> SCM systems again.
> 
> Let's just cut to the chase and discuss why we're not using git ...

Probably because git is a "stupid content tracker" according to its
very authors, and we want some real SCM? ;-)

> 
> -- Rod (who started using git recently to push kernel patches
> upstream)



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: Monotone issues

[Paul Sokolovsky]

Hello,

On Mon, 04 Feb 2008 09:31:15 +0100
Koen Kooi <k.kooi@student.utwente.nl> wrote:

[]

> Since this all was triggered by a bad commit, 

Was it? I got impression it was kinda bug in mtn?

> we should evaluate
> commit and review policy as well and ideally end up with something
> that can be hooked up to http://review-board.org/.

Oh, new toys are always sooo sweet! ;-) In the meantime, may I ask if
your exams are over and we can expect to see weekly commit/bug activity
summaries again? ;-) Maybe they even will be crontabbed?

[]
> 
> regards,
> 
> Koen
> 

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com