Re: [dev] Announcement: Migration to Mercurial
Jens-Heiner Rechtien wrote: Migration to Mercurial == [snip...] Documentation: -- Main entry point: http://wiki.services.openoffice.org/wiki/Mercurial Björn has done a beautiful job of adding a TOC for the Mercurial pages. The one problem I see is, will potential users be able to find it? Please think about where developers would look for this info, then add links there. I added one on the main wiki page. -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Maybe I've overlooked it but I haven't seen an equivalent to svn switch URL-of-CWS-or-tag With svn I had one checkout which I switched to whatever cws or tag I wanted to build and svn switch would only download the differences between my current checkout and the target. That was fast, saved bandwidth and hard drive space (believe it or not, I have to make do with an 80GB hard disk). With Mercurial it looks like I have to clone a complete repository whenever I want to build a CWS or a tag. Could someone give me the Mercurial equivalent to the following sequence of instructions: svn co http://svn.services.openoffice.org/ooo/trunk/ cd trunk svn switch http://svn.services.openoffice.org/ooo/cws/blabla # Now the current directory contains the OOo sources for CWS blabla svn switch http://svn.services.openoffice.org/ooo/tags/OOO320_m2/ # Now the current directory contains the OOo sources for milestone OOO320_m2 # NOTE: The changes from CWS blabla are NOT merged. Unless they have been incorporated in m2 by # the OOo developers, they are gone now from my checkout. # This is an important point. I am NOT looking for a way to merge changes from different trees. svn switch http://svn.services.openoffice.org/ooo/trunk/ # Now my repository is exactly as it was in the beginnig (assuming no commits happened in the mean time) As mentioned in the beginning, I'm interested in a way of doing this that is fast, bandwidth-efficient and diskspace-efficient. Matthias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Matthias, On Tue, Oct 27, 2009 at 10:58 AM, Matthias B. mux2...@gmail.com wrote: Maybe I've overlooked it but I haven't seen an equivalent to svn switch URL-of-CWS-or-tag With svn I had one checkout which I switched to whatever cws or tag I wanted to build and svn switch would only download the differences between my current checkout and the target. That was fast, saved bandwidth and hard drive space No, that wasn't really fast (IMHO). (believe it or not, I have to make do with an 80GB hard disk). With Mercurial it looks like I have to clone a complete repository whenever I want to build a CWS or a tag. If you want to have it in seperate directories: Yes, but you're cloning from your local repo anyway. And when you do it as described in the wiki-pages, mercurial will use hardlinks for the clone. This is /very/ fast and also needs virtually no additional space for the repo. Could someone give me the Mercurial equivalent to the following sequence of instructions: svn co http://svn.services.openoffice.org/ooo/trunk/ hg clone -U http://hg.services.openoffice.org/DEV300 OOo-repo cd trunk svn switch http://svn.services.openoffice.org/ooo/cws/blabla hg clone -U OOo-repo workdir cd workdir hg pull -u http://hg.services.openoffice.org/cws/blabla Alternatively you can pull to your local-master # Now the current directory contains the OOo sources for CWS blabla svn switch http://svn.services.openoffice.org/ooo/tags/OOO320_m2/ # Now the current directory contains the OOo sources for milestone OOO320_m2 # NOTE: The changes from CWS blabla are NOT merged. Unless they have been incorporated in m2 by # the OOo developers, they are gone now from my checkout. # This is an important point. I am NOT looking for a way to merge changes from different trees. just the same as above, although then you wouldn't need to pull since the milestones would be tagged in the main repo already. hg update -C (thorw away your local changes) -r OOO320_m2) svn switch http://svn.services.openoffice.org/ooo/trunk/ # Now my repository is exactly as it was in the beginnig (assuming no commits happened in the mean time) As mentioned in the beginning, I'm interested in a way of doing this that is fast, bandwidth-efficient and diskspace-efficient. Mercurial is way, way faster than svn in this regard. If fact with mercurial, I wouldn't bother modifying the existing tree, but just create another local clone. Remember to always clone the full repo (no -r argument), otherwise mercurial cannot use hardlinks (would be slow and takes much diskspace) ciao Christian - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Björn, *, On Tue, Oct 27, 2009 at 11:37 AM, bjoern michaelsen - Sun Microsystems - Hamburg Germany bjoern.michael...@sun.com wrote: On Tue, 27 Oct 2009 10:58:53 +0100 Matthias B. mux2...@gmail.com wrote: Maybe I've overlooked it but I haven't seen an equivalent to svn switch URL-of-CWS-or-tag This is certainly possible with hg. However, to use this functionality you would need multiple heads in one repository. Since this is _not_ currently supported by releng, Well, RE doesn't need to support it anyway. One needs to be aware of it, that's all. If you're consumer only, then you don't need to take care anyway, only if you are a developer and need to commit stuff, then you should remember that you're having multiple heads and that only the one you're working on is meant to be pushed. Pushing the other ones doesn't do any harm besides wasting bandwidth on a push. you are completely on your own when doing so. If you are a not yet too confident in using hg, just use multiple repositories: It uses a bit more disc space, but will likely have break-even by not breaking your repos once. It doesn't even take more diskspace. A hg workingdir: ~3.5GB - a subversion working dir: 4,4 GB A local clone doesn't take up noteworthy diskspace - only the actual sourcefiles matter (~2.1GB) But as you got the whole repo locally anyway, throwing away those 2.1 GB to make room for the other tree is cheap. No bandwidth needed, just a little I/O on your harddisk. Again: Cloning the local repo is fast. $ hg --time clone -U OOo-tip hgclone Time: real 2.140 secs (user 0.770+0.000 sys 1.130+0.000) $ cd hgclone/ $ hg --time update -r DEV300_m61 68960 files updated, 0 files merged, 0 files removed, 0 files unresolved Time: real 59.220 secs (user 41.670+0.000 sys 7.580+0.000) $ cd .. $ time rm -rf hgclone/ real0m1.551s user0m0.100s sys 0m1.450s svn switch doesn't even come close to that. So: Don't try to force your working habits to mercurial, better try to adapt your workflow to use the benefits of mercurial. As shown, theres a way to do that. However, this local repository now contains multiple heads. Do NOT DARE to hg push --force these multiple heads to an outgoing repository or the wrath of RelEng will be upon you. You have been warned(*) ;-) ...instead just use hg push -r tip, to only push the head you're actually working on. That way no bandwidth is wasted pushing unrelated branches/heads and no confusion is caused by introducing another head in the cws. ciao Christian - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Eric, looks fine and I'm looking forward to that ClassRoom. Regards, Heiner eric.bachard wrote: Hello Heiner, Jens-Heiner Rechtien a écrit : Migration to Mercurial == OpenOffice.org developers, here - as promised - some information about the migration of the DEV300 code line to Mercurial. First, thanks a lot for your great and impressive work :-) [...cut the announce... ] As we discussed, I have added Migration to Mercurial presentation we planned together in the Education Project ClassRoom agenda : http://wiki.services.openoffice.org/wiki/Education_ClassRoom/Agenda Please verify nothing is wrong, and thanks again for your participation ! Eric P.S. for Björn : a student from UTBM (Mathieu Paret, on CC) is currently working on the Education Project wiki page improvement, and we'll modernize a bit soon. If you want to discuss more about this topic, we can meet us on IRC ( #education.openoffice.org ) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: [...] As shown, theres a way to do that. However, this local repository now contains multiple heads. Do NOT DARE to hg push --force these multiple heads to an outgoing repository or the wrath of RelEng will be upon you. You have been warned(*) ;-) Best Regards, Bjoern (*) At least twice, as the docs say this pretty clearly at: http://wiki.services.openoffice.org/wiki/MercurialCws#Publishing_changes Actually, I'm thinking about a hook which will prevent the creation of new heads on the outgoing repositories. Not yet implemented, though. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 13:04:50 +0100 Christian Lohmaier cl...@openoffice.org wrote: Pushing the other ones doesn't do any harm besides wasting bandwidth on a push. Thats not entirely true. This is the way there is harm by adding superficial heads to an outgoing repo: - RelEng expects a cws repo to contain exactly one head on integration. They do not want to have to figure out which of multiple heads should be integrated. This is a reasonable requirement. - Thus all heads on an outgoing repository need to be merged before integration. Since all heads are merged into one and this one head will be integrated, everything on the cws will be integrated in the master. - Thus there is no way to have an scrap branch on an outgoing repo that will not be integrated in the master. The only way to get rid of unwanted experimental branches is to open a new cws, cherrypick branches over to the new cws and then delete the old cws. tl;dr: Do NOT create multiple heads in outgoing repos. [...] real 0m1.551s user 0m0.100s sys 0m1.450s Well, thats all true with any real OS and FS. Unfortunately, on Windows time and space requirements are quite different. ..instead just use hg push -r tip, to only push the head you're actually working on. Or, if unsure, do not create multiple heads (unless temporarily on a local repo when you do the equivalent of a cws rebase, in which case you are merging them immediately). Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Bjoern, thanks, this is looking way better and is much more usable. Regarding your idea with reorganizing the pages. I like that :-). Maybe we could just forward the old pages to the new ones (only the OOo and Mercurial one, no need to bother with rest). Regards, Heiner bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Tue, 27 Oct 2009 04:42:37 -0400 T. J. Frazier tjfraz...@cfl.rr.com wrote: Jens-Heiner Rechtien wrote: Migration to Mercurial == [snip...] Documentation: -- Main entry point: http://wiki.services.openoffice.org/wiki/Mercurial Bj__rn has done a beautiful job of adding a TOC for the Mercurial pages. Yeah, sorry. I could not keep my hands of it ;-) (and I really just found a template to copy'n paste) The one problem I see is, will potential users be able to find it? Please think about where developers would look for this info, then add links there. I added one on the main wiki page. As of now it is linked from: - Main Page - Main Page - I want to be an OpenOffice.org developer - Main Page - Build Environment Effort - Main Page - Building Guide - Category:Mercurial - Category:SCM - Category:Development (Entry Page only) - Category:CWSTooling (were relevant) - I did not add Category:Build System and Category:Quality Assurance to not dilute them. Anything missing? Actually I think in the long run (in 6 month, after migration), it would not need to be on the Main Page anymore as current devs would know about it and newcomers will find it in the I want to be ... and Building Guide Pages. But now, its great to have it on the frontpage. Thanks for adding it! Best Regards, Bjoern Michaelsen P.S.: I was wondering if it would be a good idea to move the pages to subpages matching their current title. Of course one would keep the redirects from the historic titles to keep the links from the Mailing Lists working. OOo and Mercurial - Mercurial/Getting Started MercurialCws - Mercurial/CWS MercurialTipsAndTricks - Mercurial/TipsAndTricks MercurialMigration - Mercurial/Migration Opinions? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 14:22:31 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Actually, I'm thinking about a hook which will prevent the creation of new heads on the outgoing repositories. Not yet implemented, though. This time, unlike last time, I am against such a hook. ;-) If somebody creates multiple heads on an outgoing repo, no harm was done to the master. This is different than with SVN. However, it has to be clear that such a repo will never be integrated unless all heads are merged. Still, having such repos on outgoing might be of value for experimental minibranches, where one is not certain if they might get integrated one day. When those are on outgoing repos: - They are on backup as long as it is uncertain if they will make it to the master. - They can be easily merged into real cws for integration once they seem fit for it. - They can be simply deleted with the repo if they prove faulty. Nothing of value will be lost. If you want to make absolutely clear that a cws wont be integrated when its repo has multiple heads, I would propose to add another Test to EIS showing this nifty stopsign and scary red boxes, if the cws repo has multiple heads. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Bjoern, let's see if there are accidental new heads on the outgoing repository. No need to have a hook for something that never happens anyway. Best regards, Heiner bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Tue, 27 Oct 2009 14:22:31 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Actually, I'm thinking about a hook which will prevent the creation of new heads on the outgoing repositories. Not yet implemented, though. This time, unlike last time, I am against such a hook. ;-) If somebody creates multiple heads on an outgoing repo, no harm was done to the master. This is different than with SVN. However, it has to be clear that such a repo will never be integrated unless all heads are merged. Still, having such repos on outgoing might be of value for experimental minibranches, where one is not certain if they might get integrated one day. When those are on outgoing repos: - They are on backup as long as it is uncertain if they will make it to the master. - They can be easily merged into real cws for integration once they seem fit for it. - They can be simply deleted with the repo if they prove faulty. Nothing of value will be lost. If you want to make absolutely clear that a cws wont be integrated when its repo has multiple heads, I would propose to add another Test to EIS showing this nifty stopsign and scary red boxes, if the cws repo has multiple heads. Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 14:25:40 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Regarding your idea with reorganizing the pages. I like that :-). Maybe we could just forward the old pages to the new ones (only the OOo and Mercurial one, no need to bother with rest). All pages moved, all wiki internal links updated. Redirects are in place (thats the default when moving). Maybe we can remove the redirect pages in 6 month when this stuff is old. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi *, On Tue, Oct 27, 2009 at 3:49 PM, Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Hi Bjoern, let's see if there are accidental new heads on the outgoing repository. No need to have a hook for something that never happens anyway. IMHO this is already guaranteed by mercurial itself. Forcing something is always a bad idea, so whoever forces a commit despite the warning surely doesn't do that by accident. ciao Christian - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Announcement: Migration to Mercurial
Migration to Mercurial == OpenOffice.org developers, here - as promised - some information about the migration of the DEV300 code line to Mercurial. The next milestone DEV300 m63 will be the last milestone published via SVN. Newer milestone will only be available from the Mercurial repository (http://hg.services.openoffice.org/DEV300). The SVN server will still be available for some time to come. Please continue your work on your existing SVN hosted child workspaces as usual. You don't need to migrate your CWS immediately. You are only required to migrate your CWS if you need to update it to DEV300 m64 or later. Please see the migration guide for details. From now on, new child workspaces should be Mercurial hosted. You will still be able to create a new DEV300 m63 based SVN hosted child workspace, but this just means unnecessary migration work later. Please don't hesitate to contact me per email or IRC if you have questions. My IRC nick is 'blauwal'. Documentation: -- Main entry point: http://wiki.services.openoffice.org/wiki/Mercurial Setting up Mercurial: http://wiki.services.openoffice.org/wiki/Setting_up_Mercurial Basic hg usage: http://wiki.services.openoffice.org/wiki/OOo_and_Mercurial CWS handling: http://wiki.services.openoffice.org/wiki/MercurialCws Migrating child workspaces to Mercurial: http://wiki.services.openoffice.org/wiki/MercurialMigration If you find errors in the documentation, not just technical errors but also embarrassing spelling and grammar mistakes, please feel free to correct them. It's a Wiki after all. Regards, Heiner -- Jens-Heiner Rechtien OpenOffice.org release engineer h...@openoffice.org jens-heiner.recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
