Re: [dev] Mercurial Pilot Feedback, Results
Thorsten Ziehm wrote: Not difficult if you ignore problems ;-( I don't think, that Heiner ignore problem reports. He was very open for comments for this pilot and did a lot to evaluate problems. As you can read he has listed positive and also negative feedback. Also your feedback is listed with the result he had taken from the discussion. No, it's listed with what he told me in the discussion. Which was frankfly speaking not a discussion at all but he just pointing out what he pointed out in this summary. Again, I don't believe the arguments at all a) our mercurial package *has* .sos and is still slow - the native libs argument doesn't hold. He didn't even tell me what I should check when I asked him. At least Debians mecurial package is not at fault. b) he said the low mem/slow cpu/slow(er) hd combination was at fault That does not explain why it's equally slow on a (quite) up-to-date machine. So please be constructive with your feedback and be friendly. I am. Regards, Rene - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Mercurial Pilot Feedback, Results
Jens-Heiner Rechtien wrote: Scalability: - overall perceived good performance, some were even quite enthusiastic about it (SVN users are easy to please ...). - there were three mentions of sub-par performance which all have been investigated shortly: - unexpected slow clone times on a very old machine with slow disks and little memory: this machine was probably simply underpowered for use with Mercurial, which is somewhat memory intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. If that was true, please tell me why it also was that slow on my MacBook 2Ghz, 1GB RAM with (quite) fast disk, not an old like my Mac mini G4 with 512M RAM? But I told you that at that time, too - unexpected slow update of the working tree: caused by using the pure python replacements instead of the hg native shared libs. This should be avoided by any project of the size of OOo. You didn't read what I wrote. How please is http://packages.debian.org/lenny/mercurial not using native libs? (See the libc6 dependency and the .sos). Conclusion: === The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some Not difficult if you ignore problems ;-( Regards, Rene - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Mercurial Pilot Feedback, Results
[ forgot something ] Jens-Heiner Rechtien wrote: intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. There wasn't actually, I just followed your pilot documentation 1:1. If that sucked you can't blame it on the person using that documentation. Regards, Rene - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Mercurial Pilot Feedback, Results
Hi Rene, Rene Engelhard schrieb: Jens-Heiner Rechtien wrote: Conclusion: === The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some Not difficult if you ignore problems ;-( I don't think, that Heiner ignore problem reports. He was very open for comments for this pilot and did a lot to evaluate problems. As you can read he has listed positive and also negative feedback. Also your feedback is listed with the result he had taken from the discussion. When I take a look at your type of communication at that time, I can understand when somebody isn't willing to communicate with you at all and isn't willing to read all your comments. But I don't think that Heiner did this. So please be constructive with your feedback and be friendly. Thanks, Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Mercurial Pilot Feedback, Results
Hi Rene, please see my comments inline, Rene Engelhard wrote: Jens-Heiner Rechtien wrote: Scalability: - overall perceived good performance, some were even quite enthusiastic about it (SVN users are easy to please ...). - there were three mentions of sub-par performance which all have been investigated shortly: - unexpected slow clone times on a very old machine with slow disks and little memory: this machine was probably simply underpowered for use with Mercurial, which is somewhat memory intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. If that was true, please tell me why it also was that slow on my MacBook 2Ghz, 1GB RAM with (quite) fast disk, not an old like my Mac mini G4 with 512M RAM? But I told you that at that time, too - unexpected slow update of the working tree: caused by using the pure python replacements instead of the hg native shared libs. This should be avoided by any project of the size of OOo. You didn't read what I wrote. How please is http://packages.debian.org/lenny/mercurial not using native libs? (See the libc6 dependency and the .sos). You shouldn't think that only you have problems here and there :-) This bullet point was about an observation by Mikhail, and we think we have tracked it down to this problem. Conclusion: === The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some Not difficult if you ignore problems ;-( I certainly do not ignore problems. I may come to different conclusions at that time, but I do not ignore them. I even blogged about it at that time. Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Mercurial Pilot Feedback, Results
OOo developers, last week I asked the participants of the Mercurial pilot for feedback. Most have responded and I think we are now able to wrap up the pilot and come to a conclusion. Over the last eight weeks 21 child workspaces have been created and worked on, three of them went the full way until being integrated back into the main code line. You can find an overview here: http://hg.services.openoffice.org/hg The responses covered a whole range of topics, which I try to break down in the following: Functionality: == - most importantly, no participant complained about missing functionality. - one participant mentioned that he's more comfortable with the git feature set, but added that he's also way more experienced with git. - at least one participant was positively surprised by some unexpected but very useful functionality, for example the powerful template engine. Disclaimer: that would be me ... Scalability: - overall perceived good performance, some were even quite enthusiastic about it (SVN users are easy to please ...). - there were three mentions of sub-par performance which all have been investigated shortly: - unexpected slow clone times on a very old machine with slow disks and little memory: this machine was probably simply underpowered for use with Mercurial, which is somewhat memory intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. - unexpected slow update of the working tree: caused by using the pure python replacements instead of the hg native shared libs. This should be avoided by any project of the size of OOo. - very slow push to outgoing rep. via async DSL after pull/merging the DEV300_m51 milestone: caused by an over sized changeset in DEV300_m51, which moved 40% or so of our tree to another place. Very nice test for a worst case behavior. Emphasizes the need of server side copies for creating the outgoing repositories. - storage efficiency in the case of renamed large files is worse than what is possible with git. Ease of handling/Learning curve: - got a lot of positive feedback here and one neutral (like git better but don't know yet enough about hg to judge it fair) - a complete and working infrastructure (build bots, opengrok, required changes to build.pl, a hg plugin which deals with EIS and many other tools) need to be in place before we could start with production use. Conclusion: === The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some improvements here and there, but all-in-all the majority of the pilot participants is pleased with its functionality, scalability and especially the ease of handling. With an overall positive outcome of the pilot we move over to next phase: the implementation of a full scale migration to Mercurial. I'll keep you posted about the details. Thanks: === I would like to thank all the pilot participants for their work and their valuable discussions and insights. Regards, Heiner -- Jens-Heiner Rechtien h...@openoffice.org recht...@sun.com OpenOffice.org release engineer - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Mercurial Pilot Feedback, Results
With an overall positive outcome of the pilot we move over to next phase: the implementation of a full scale migration to Mercurial. I'll keep you posted about the details. Great to hear that! Though I haven't used it in the OOo pilot, I did use it on some other projects and pilots and I'm looking forward to the transition. - Max - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
