Re: [tools-dev] Re: HG changegroup.notify hook raised an exception
Hi, On 01/12/2011 11:45 AM, Michael Stahl wrote: On 12/01/2011 09:12, Stephan Bergmann wrote: $ hg push ssh://h...@hg.services.openoffice.org/cws/sb139 pushing to ssh://h...@hg.services.openoffice.org/cws/sb139 searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 186 changesets with 1567 changes to 881 files remote: error: changegroup.notify hook raised an exception: remote: abort: Not enough space abort: unexpected response: empty string i think this is caused by the changelog mail being too big. so there is probably no notification on allhg of your commit. but the push itself should be complete. Changelog Mails are send by the changegroup hook and that one kicks in when everything is already pushed and accepted by the server. No Problem. The exception occurs when the length of the Changelog Mails exceed certain obscure limits in the Python email classes (email.Parser.Parser.parsestr()), it *might* go away when we update the python version on the server, who knows - they did overhaul the email classes in the meantime. but i'm not sure exactly in which way it is too big. the number of changesets can't be the (only) criterion. $ hg --version Mercurial Distributed SCM (version 1.7.3) happened for me with older versions as well. Well, the client version has nothing to do with it, this happening remote ... Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi, On 06/03/2010 05:55 PM, Björn Michaelsen wrote: Am Thu, 03 Jun 2010 17:28:00 +0200 schrieb Jan Holesovskyke...@suse.cz: Ah yeah, the magical touch of git which is able to make huge compressed changesets much smaller, almost vanishing in size. :-) Git might have a smaller storage for a given repository, granted, but I somehow doubt that it's able to transfer huge changesets much faster than Hg. Indeed, git is magical ;-) In this case, on the server, the CWS wouldn't be separate trees, but branches (in the git meaning of the word), and so you wouldn't have to push all the changes that happened in DEV300 in the meantime (if you have them in another brach, they are reused) - ie. exactly what Christian wants. Never in life I would want to have all branches (CWSs) in one repository. No way. Not with hg and not with git. Such things work well in a pull-only environment. But when every dev can push something to the rep. they need necessarily be separated - so I can simply drop the whole rep. if someone pushes something very stupid. And yes, these things happen. Just as mercurial would do if we would be using a multiple head repo instead of multiple heads. So git is no more magical there than hg. ;) And even if they were separate trees, you are able to setup the trees (CWSes in this case) trivially to search for the missing commits (and objects, etc.) in the main tree (DEV300) first using 'alternates', before expecting the client to push them all. This is exactly what I meant with reference rep. in the postscriptum of my mail to Christian. I'll look into it if this is possible with mercurial. Again that would actually be just as trivial with hg if we would not have that one head repos!!1!eleven! dogma. For example a hook could simply pull from DEV300 before applying a changeset. Or even simpler a cronjob pulling from DEV300 to the cws repos regularly would solve the problem. IMHO most devs are able to handle a two-head (master and cws) repo easily by now. But I guess Heiner has another opinion. Most devs ..., yes. But we need everyone to handle this right. Remember, there are non-devs who also need to work with the setup. And, judging by the questions I have been answering lately, we aren't yet there to try out the fancy stuff :-) Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi Christian On 05/31/2010 10:08 PM, Christian Lohmaier wrote: Hi *, On Mon, May 31, 2010 at 7:41 AM, Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: [...] a) Most important, if there are already developer changes in the CWS (which will be the standard case) such a remote update will create a new head which will be very confusing for many users, since we have adopted a strict one head only policy for the outgoing repositories. I don't see this as a problem, as the pull is triggered so that the merge-push of the developer doesn't take that long. The intention is to trigger the remote-pull, wait a minute or two, then push the merge that is done locally already. So yes, there will be two heads, but just for the minute or two the developer has to wait for the remote pull to complete. This opposed to half an hour or more for a complete push is quite a difference. Agreed, it's probably not much of a problem if the server side rep. has two heads for a short time frame. Prolonged phases with two heads could be a problem if a CWS is shared by multiple developers and the second head is not expected by some. Remote merge is not possible (no working trees, no one to solve potential conflicts). Well, no need for remote merge, just for getting all those unrelated-to-the-actual-cws commits faster The developer still merges locally. b) It doesn't really fit into the framework. Too bad :-( [...] Thus the only way to implement that would be the introduction of a new flag (remote_pull_requested) in EIS which would than be polled by another server side script. Too bad. If it is polled, and not executed right after it was requested, it will be very hard to determine when the real push of the merge can start :-/ - sending an email when it is done would be the only solution. But if that it is only polled every 5 hours, then that delay again outweighs the benefit :-/ [...] Not sure if this added complexity is worth the IMHO quite narrow use case - it's the first time I've heard such a request. That I'm the first to voice it in a concrete request doesn't mean that I'm the first to complain. Hang out on the corresponding IRC channels, and you'll tons of complaints or sarcastic jokes (usually followed by how much more that developer loves git ;-) about that... Ah yeah, the magical touch of git which is able to make huge compressed changesets much smaller, almost vanishing in size. :-) Git might have a smaller storage for a given repository, granted, but I somehow doubt that it's able to transfer huge changesets much faster than Hg. But then, making these sarcastic jokes in IRC channels where I do hang around might draw an informed response and that would certainly spoil the fun :-) I'm always willing to lend a hand with the CWS update if someone sends me an email with such a request. If I receive many such requests I'll certainly consider to automate this :-) Depends on the roundtrip I guess. As for me it would very likely be week-end, Waiting for your intervention/reply would be longer than clogging my bandwidth overnight :-P Yep, that could happen on a weekend :-) PS: It's an interesting idea to implement in a server side extension of Mercurial: If, during a push to remote, a comparison of the local rep. changesets with the remote changesets yields a list of changesets which are not yet remote available, consider first to consult another remote well known reference repository for the changesets, pull any possibly available changesets from there and then renegotiate the list of missing changesets with the local repository. Don't know if this is easy to implement but it could be worthwhile for monster repositories as well (like OOo). Thinking about it, it's even an option for the local side on a pull. Yes, that would do the trick as well, although that (in my eyes) seems to be more complicated to implement (as it seems would require changes to the client as well, but I don't have no understanding whatsoever on how pushing and receiving side decide on what needs to be transferred and what is already available on the receiving side)... The sending client does not need to have these changes in place, so it would fit quite nicely in our case here. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi Christian, ADSL being what it is, a push to an old CWS which has been updated to a more recent milestone can be quite slow, especially if one of the milestone contains a whole set of new localizations, agreed. I've thought about a remote update of the outgoing repositories, but it isn't that easy. a) Most important, if there are already developer changes in the CWS (which will be the standard case) such a remote update will create a new head which will be very confusing for many users, since we have adopted a strict one head only policy for the outgoing repositories. Remote merge is not possible (no working trees, no one to solve potential conflicts). b) It doesn't really fit into the framework. The repositories are quite independent from EIS, the only way to change the content of a outgoing repository is via a push over ssh with a hg client, using the hg protocol (which has no provision for this). EIS has no direct access to the repositories (nor should it have), the only connection between the two is a little script on the server which regularly polls EIS for new, not yet created CWSs. Thus the only way to implement that would be the introduction of a new flag (remote_pull_requested) in EIS which would than be polled by another server side script. Since the execution and succesful termination of that script isn't easily observable from the outside, the script would additionally need to send emails. Not sure if this added complexity is worth the IMHO quite narrow use case - it's the first time I've heard such a request. I'm always willing to lend a hand with the CWS update if someone sends me an email with such a request. If I receive many such requests I'll certainly consider to automate this :-) Regards, Heiner PS: It's an interesting idea to implement in a server side extension of Mercurial: If, during a push to remote, a comparison of the local rep. changesets with the remote changesets yields a list of changesets which are not yet remote available, consider first to consult another remote well known reference repository for the changesets, pull any possibly available changesets from there and then renegotiate the list of missing changesets with the local repository. Don't know if this is easy to implement but it could be worthwhile for monster repositories as well (like OOo). Thinking about it, it's even an option for the local side on a pull. On 05/27/2010 07:12 PM, Christian Lohmaier wrote: Hi *, As rebasing a cws with ADSL is a pain because of the slow upload link, I wondered whether it would be possible to add a cws pullremote -mmilestone or similar command to cwstools. Those would then pull the changes up to that given milestone into the remote cws clone. Thus the only thing that would be pushed from the developer's machine would be the actual merge commits. Much less bandwidth spent that way, and even more important: Much time saved. Would it be possible to add that functionality? ciao Christian - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] The OOo HG and SVN server is down
Hi, the OpenOffice.org SCM server for the Mercurial and Subversion repositories is down. Other services (for example the OpenGrok indexer) hosted on the server are affected as well. We are working on this. Sorry for the inconvenience, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Creating a cws from EIS: Not possible to choose state new
Hi Bernd, thanks for making the change. Regards Heiner On 03/04/10 17:17, Bernd Eilers wrote: ReHI! Setting a CWS initially to state new and changing a CWS in state planned to new is now allowed by EIS and creating a HG CWS can be done as described in the Wiki. Kind regards, Bernd Eilers Jens-Heiner Rechtien wrote: Hi Bernd, Am 03.03.10 17:53, Bernd Eilers schrieb: Christian Lohmaier wrote: Hi *, Hi, Mercurial documentation as well as previous mails concerning this topic describe that you can create a cws in EIS, and that the outgoing repo is created when setting the state to new. http://wiki.services.openoffice.org/wiki/Mercurial/Cws#Creating_the_child_workspace_in_EIS reads: As an alternative way you can use the EIS web fronted to create the CWS and set it to status 'new'. Don't forget to set the SCM property to 'HG'. But that's not possible, as the only choices available are planned and finished. Whoever wrote that paragraph didn't request a corresponding feature for EIS from tooling :-( Ah, that someone would be me ... I didn't realize that without having some administration rights (which I have) it's not possible to do so. What you can do is to create a CWS in EIS setting it to plannned initially and some time later than use the cws create command on the commandline afterwards to really create it and set it´s state to new. This should work for currently used HG and previously used SVN SourceCode Control Mangement systems. Setting a planned CWS to 'new' or initially setting to 'new' is currently probably only possible with some administrator rights in EIS. If we would want to be able to directly set the CWS to 'new' in EIS for HG based ChildWorkspaces for everyone we could probably add such a feature, but it would eventually be some kind of tricky how to allow that than for HG based CWS and disallow that for other CWSs which are using other SCMs. This point is alomost completely moot since all interesting code lines are now on HG. And even with SVN (CVS is not a problem since modules are tagged separately) all hope is not lost if someone switches a CWS from planned to new without creating a CWS branch (via cws create) ... you can always do it later with the cws create --migrate switch. I would vote for allowing this. Tschau Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Creating a cws from EIS: Not possible to choose state new
Hi Bernd, Am 03.03.10 17:53, Bernd Eilers schrieb: Christian Lohmaier wrote: Hi *, Hi, Mercurial documentation as well as previous mails concerning this topic describe that you can create a cws in EIS, and that the outgoing repo is created when setting the state to new. http://wiki.services.openoffice.org/wiki/Mercurial/Cws#Creating_the_child_workspace_in_EIS reads: As an alternative way you can use the EIS web fronted to create the CWS and set it to status 'new'. Don't forget to set the SCM property to 'HG'. But that's not possible, as the only choices available are planned and finished. Whoever wrote that paragraph didn't request a corresponding feature for EIS from tooling :-( Ah, that someone would be me ... I didn't realize that without having some administration rights (which I have) it's not possible to do so. What you can do is to create a CWS in EIS setting it to plannned initially and some time later than use the cws create command on the commandline afterwards to really create it and set it´s state to new. This should work for currently used HG and previously used SVN SourceCode Control Mangement systems. Setting a planned CWS to 'new' or initially setting to 'new' is currently probably only possible with some administrator rights in EIS. If we would want to be able to directly set the CWS to 'new' in EIS for HG based ChildWorkspaces for everyone we could probably add such a feature, but it would eventually be some kind of tricky how to allow that than for HG based CWS and disallow that for other CWSs which are using other SCMs. This point is alomost completely moot since all interesting code lines are now on HG. And even with SVN (CVS is not a problem since modules are tagged separately) all hope is not lost if someone switches a CWS from planned to new without creating a CWS branch (via cws create) ... you can always do it later with the cws create --migrate switch. I would vote for allowing this. Tschau Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] ANNOUNCEMENT: OOO320 release code line goes Mercurial
ANNOUNCEMENT: OOO320 release code line goes Mercurial = With the OOo 3.2 release safely out of the door we'll switch the OOO320 release code line (or rather now: maintenance code line) to Mercurial. The next milestone on this code line will be Mercurial only. Please find the OOO320 repository here: http://hg.services.openoffice.org/OOO320 A nightly mercurial bundle for speedier download can be found here http://hg.services.openoffice.org/bundle/OOO320.hg Starting with the next milestone OOO320 m13 you should be able to work with this code line in the same fashion as you do with the DEV300 code line. If you need a CWS on OOO320 m12 basis now (or if you have an existing CWS already) you can and should stay with SVN. We'll do the migration SVN-HG when your CWS is nominated for integration. In the case that you need to update a SVN based CWS to a milestone OOO320 m13 or later (very rare on this code line), please mail me (h...@openoffice.org) and we'll arrange for the migration. Best regards, Heiner -- Jens-Heiner Rechtien OpenOffice.org release engineer h...@openoffice.org jens-heiner.recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Please read: SVN and HG server maintenance
Hi, the new disk has been successfully installed and the RAIDZ pool on the system has been resilvered. The OOo SCM server is now again working with full speed and reliability. Regards, Heiner Jens-Heiner Rechtien wrote: Hi, the OpenOffice.org SCM server for HG and SVN (hg.services.openoffice.org, svn.services.openoffice.org) will be rebooted tonight (Dec. 21/22, around midnight CET) for disk replacement. This will take just a few minutes. Hot swapping the disk should have worked, but failed for some reasons. The broken disk was also responsible for the terrible performance of the server in the last few days. It's now taken offline until the replacement, so performance should be almost nominal. Please don't schedule long running HG or SVN jobs today and do not access the HG or SVN services during the reboot. Thanks Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Please read: SVN and HG server maintenance
Hi, the OpenOffice.org SCM server for HG and SVN (hg.services.openoffice.org, svn.services.openoffice.org) will be rebooted tonight (Dec. 21/22, around midnight CET) for disk replacement. This will take just a few minutes. Hot swapping the disk should have worked, but failed for some reasons. The broken disk was also responsible for the terrible performance of the server in the last few days. It's now taken offline until the replacement, so performance should be almost nominal. Please don't schedule long running HG or SVN jobs today and do not access the HG or SVN services during the reboot. Thanks Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] GCC 3.x.x support
Hi, after some discussion on the tools mailing list and with the port maintainers it has been decided that we'll drop support for certain obsolete gcc versions. GCC versions which are supported by the OOo build system - gcc-4.x.x is supported - gcc-3.3.x is not longer supported, patches aren't any longer accepted - gcc-3.4.x is deprecated, patches will be accepted up to including OOO330. Build breakers can't be flagged as Prio 1, fixes will have to come from the port maintainers using this obsolete version as most developers will not have a way to fix or even to verify the build problem. I've updated http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers accordingly. Regards, Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Announcement: OpenOffice.org development switches to Mercurial as SCM
ANNOUNCEMENT OpenOffice.org developers, I'm very pleased to announce, that after five months of piloting, implementation and and testing, we are finally ready to switch OpenOffice.org development to Mercurial (hg) as our SCM (Source Code Management) tool. Mercurial is a modern and flexible distributed SCM tool with the fast and convenient merging capability which is so required for OOo development. We have chosen Mercurial out of the three major open source DSCM tools available (Git, Bazaar and Mercurial) because we believe that its combination of ease of use, flexibility and performance fits best with the overall OOo needs. We are well aware that a slightly different emphasis on the selection criteria might well have led to a choice of Git or Bazaar, which are both very capable DSCMs as well. Details: We'll switch the DEV300 development code line first, the OOO320 (OpenOffice.org 3.2 release code line) will follow later. We certainly don't want to interfere with the OOo 3.2 release. The DEV300 switch will happen around the 26th of October. The current DEV300 hg mirror repository on hg.services.openoffice.org will be elevated to *the* reference repository, where release engineering pushes released milestones. Simultaneously release engineering will stop to commit new milestones to the current Subversion (svn) trunk. Please stay tuned! During the course of the next two weeks I'll make a number of announcements regarding the switch to Mercurial: - where to find documentation - which will be the last svn based milestone - conversion of child workspaces to hg - conventions which we will use Regards Heiner -- Jens-Heiner Rechtien OpenOffice.org release engineer h...@openoffice.org jens-heiner.recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Warn recent changes in files being deleted: does it make sense?
Hi Ian, Ian Clatworthy wrote: Jens-Heiner Rechtien wrote: Sure, but there is no need to rely on heuristics where none is needed. Heuristics are good enough in many cases. Metadata + heuristics is better though. Back to the original use case which triggered this thread. If you do rename of a Java class in an IDE then not only the file name will be changed but also quite a number of places inside the file. Relying here on heuristics, is asking for trouble, I think. The IDE should simply issue a SCM rename operation IMHO. Be explicit where possible. And if you rename a Java package, it's nice if your VCS can capture that too (by recording a directory rename). Yep and this is one of the places where Bazaar shines - and SVN, too, for the matter, but SVN still can't forward changes. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Warn recent changes in files being deleted: does it make sense?
Hi Stephan, Stephan Bergmann wrote: On 10/06/09 14:02, Jens-Heiner Rechtien wrote: How should any SCM detect filesystem only renames? This is just asked to much. You have to use hg rename, of course. Anything else would have to rely on heuristics which might fail, hardly something a SCM can do. *Everything* an SCM does when it comes to merging changes (be it to individual files or to a complete file hierarchy) relies on heuristics and can fail. The only correct way that could never fail would be to declare there are already changes made to the repository you want to commit to, please resolve the mess manually and not do any automatic merging. (Not the behavior you would expect, though. Also see http://blogs.sun.com/GullFOSS/entry/mistaking_version_control_for_collaboration.) Sure, but there is no need to rely on heuristics where none is needed. Moving files around is one such case. Doing a hg rename or git mv tells the SCM: These file have a common history and I want changes to the old file forwarded to the new file. Deleting and adding a file in another place means don't bother to forward changes, I don't want them, these files are no longer related. Both are valid use cases and I think developers should be required to explicitly state what they want. But, hey, it's ok to use lazy heuristics as long as no one comes along and complains when things are forwarded where it shouldn't be and the other way round. Back to the original use case which triggered this thread. If you do rename of a Java class in an IDE then not only the file name will be changed but also quite a number of places inside the file. Still, the files are related and forwarding changes should work. How much changes to a file will the heuristic allow and still consider the files related? Relying here on heuristics, is asking for trouble, I think. The IDE should simply issue a SCM rename operation IMHO. Be explicit where possible. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] should we drop gcc3 support ?
Hi Eric and Christian, so MacOSX is out of the picture with gcc-3.3 as well. Good. Now we just need a word from the *BSD side regarding gcc-3.4. My proposal still stands: - gcc-4.x.x is supported - gcc-3.3 is not longer supported, patches aren't any longer accepted - gcc-3.4 is deprecated, patches will be accepted up to including OOO330. Build breakers can't be flagged as Prio 1, fixes will have to come from the port maintainers using this obsolete version as most developers will not have a way to fix or even to verify the build problem. If I hear nothing in to the contrary for a week or so, I'll officially announce this as new policy regarding gcc support. Thanks Heiner Christian Lohmaier wrote: Hi *, On Thu, Oct 1, 2009 at 10:44 PM, eric b eric.bach...@free.fr wrote: Le 1 oct. 09 à 12:43, Jens-Heiner Rechtien a écrit : Aqua-OOo is not supported on Mac OS X 10.3 - at least I don't know anyone who ever did an aqua build that would run on 10.3. So dropping gcc-3.3 would only affect X11-MacOSX. Is that one still relevant at all? In fact, nobody knows really : the X11 version is no longer maintained. Yes, and I don't know a signle reason why anyone would want to use an X11 version instead of the aqua version. So it is in my opinion not relevant at all. Does it still work? Maybe it's possible to build it using gcc 4.0.1. Not tested since a long while :) My humble opinion is: I got tiger on several machines. Tiger is the oldest maintained version, and gcc 4.0.1 is the one shipped with. Fully agree - on mac 4.0.1 is the baseline, gcc 3.x is not needed at all ciao Christian - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Warn recent changes in files being deleted: does it make sense?
Hi, the good news that hg (as well as the other DSCMs) is able to detect these cases and do the right thing. Things should improve here RSN. Regards, Heiner Caolán McNamara wrote: On Sat, 2009-10-03 at 09:31 +0900, Takashi Ono wrote: Hi all, I think if there exist recent changes in files being deleted in a integration of a cws, they should be automatically warned to RE. Is it considered in the standard of procedures? The background is i#105542. The file solenv/inc/wntgcci6.mk is deleted and added with a new name solenv/inc/wntgcci.mk. But because of the change of the name, recent update on the file got lost. Well, svn move, but that's what a move does unfortunately. Ideally a svn move in a cws would propagate as that onwards in the merges, i.e. apply all other pending changes to the file from other cwses, and then at the end the move takes place on the merged file. Tricky I guess, unfortunate when there a rename and content changes arrive together at integration time. C. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Update: Mercurial-Implementation
Hi, I made the following changes to the mercurial setup 1) hg.services.openoffice.org is now a virtual host: This means the HTTP access URLs can be simplified and are now similar to the SSH URLs. DEV300: OOo http://hg.services.openoffice.org/DEV300 CWS mycws: OOo http://hg.services.openoffice.org/cws/mycws Please note, that the old URLs like http://hg.services.openoffice.org/hg/DEV300 (note the additional /hg) continue to work, they are aliased. 2) Email notifications When an outgoing repository has been created the CWS owner will now get an email notification. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Re: [tools-tinderbox] Tinderbox now also gathers checkin data for mercurial (flag hg based trees as dirty, etc)
H Christian,
great work! This really helps. Thanks for supporting the migration efforts.
Regards,
Heiner
Christian Lohmaier wrote:
Hi *,
I'm proud to announce that tinderbox will now also show checkin-data
for mercurial based cws.
If you experience any problems, have general feedback on the feature,
please don't hesitate to write a mail/ping me on IRC.
What is the feature about?
Tinderbox checks for changes in the cws. If a change did occur after a
build has started, the results of that build is invalidated, the tree
is flagged as dirty. This is represented with the purple color on the
status-pages.
This allow builders to requeue/rebuild cws based on that status and
even more important allows QA and DEV to judge whether the build
results actually reflect the current status of the code that was
checked in.
See for example
http://tinderbox.go-oo.org/fwk116/status.html
As of now, the MacIntel result is flagged as dirty with the purple color.
The previous build result (build failed) is no longer valid, since
there have been commits in the meantime.
The column on the left shows the commit-times along with the committing user.
To view the actual checkin-data either click on the times on the very
left, or open the popup by clicking the name of the committer and
choose the links there.
The VC-page will then show detailed info - (commit-message, affected
files, link to changeset on hg.services.openoffice.org)
Please report any problems, be it with the HG based cvs and also with
the vc-display for svn based cws (where it is unfortunately not
possible to provide links to a site with the actual diff, since
svn.services.ooo doesn't support it). Could be that I introduced a
regression or two :-)
ciao
Christian
PS: the login data is gathered via a local repository.
* the hg id cwsurl is queried and compared to the last seen
revision. If both are the same, processing ends.
* the cws is pulled into the local repository (hg pull cwsurl)
* the log is requested using the template mechanism (thanks to Heiner
for that hint)
hg --cwd $hgrepodir log --follow -P $old_id -r $current_id:$old_id -d
$lastcheckeddate --template $template
(where lastcheckddate is mainly used to limit the results when there
is no old_id yet (then old_id is 0 - lastcheckdate is then set to 14
days in the past)
And for the really curious: the template is as follows:
my $template =
'{node|short}.$sep.'{date|hgdate|user}'.$sep.'{author|user}'.$sep.'{desc|escape|addbreaks}'.$sep.'{file_adds}'.$sep.'{file_dels}'.$sep.'{file_mods}'.$record_sep.';
PPS: anyone else finds it strange, that there is a |firstline filter,
but no filter like |all_but_firstline?
-
To unsubscribe, e-mail: tinderbox-unsubscr...@tools.openoffice.org
For additional commands, e-mail: tinderbox-h...@tools.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Line-endings in source files
Hi, Christian Lohmaier wrote: Hi *, it seems to me that lately a huge amount of lineend-changes did occur. Maybe it is just a bad impression because many of the cws I had a look at lately did cause so many unrelated changes, but still: *Please* take care of lineendings before you commit. especially: please don't create files with mixed lineendings. I can only emphasize how important this is. Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Mercurial repo cloning
Hi, Bjoern Michaelsen wrote: Guido Ostkamp ooo at ostkamp.fastmail.fm writes: Hello, from recent mails I noticed the http://hg.services.openoffice.org/hg page. At the right side, there are some icons e.g. to get http://hg.services.openoffice.org/hg/DEV300/archive/tip.tar.bz2. What does this compressed tarball contain? Just a snapshot of the *working tree* of the tip without history? Yes (and a bit metainfo like of which revision this is a snapshot). It is pretty much what you get by using hg archive. How large is that file? Depends of the cws and the compression algorithm. Bzip2-Tarball of DEV300: ca. 400MB Please also note that these downloads are not there intentionally - I guess this is just how the multirepo webinterface of hg looks like by default. So I wouldnt count on these links being there after the pilot (although they might as well be). Well they are there intentionally, I wanted to get a bearing on how useful they are. And they come for free with the hgweb webinterface. I can imagine that we will customize the default web interface until no one can recognize it anymore :-) but for the beginning I like it the way it is. Guessing from the subject of your mail, I think you want a tarball of the repo with history. The most efficient way to get something like that would be a hg bundle. That would be a 730MB download for DEV300 as of now. We probably will have such a bundle available after the pilot (ask Heiner). As of now, you will need to hg clone from http://hg.services.openoffice.org/hg/DEV300 if you do not have the repo somewhere locally (takes between 4000-7000 sec, so better do that overnight). Keep in mind that this download is needed only once per dev/dev lab/location. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Mercurial-Implementation: OOo domain developer public keys
Hi OOo Mercurial users, OOo domain developers public keys = The SVN public keys of all OOo domain developers can now be used to r/w access the outgoing mercurial repositories on hg.services.openoffice.org via SSH (ssh://h...@hg.services.openoffice.org/cws/*). It's no longer necessary to be part of the Mercurial Pilot (which has been concluded weeks ago anyway) or to contact RE if you want to try out a Mercurial based CWS. There are still some caveats with Mercurial based child workspaces as long as we still use SVN for tracking our code lines: * Your changesets will loose their identity during integration. This might create problems if you cross merged changesets between several CWSs. * Integration into SVN will lump all changeset of your CWS into one single changeset. The single changeset commit during integration will contain of course only a single commit log. We lump together all commit logs and authors of your changesets together via scripting and attach that to the commit. Alternatively REs will accept a detailed commit log supplied by you. The * Be careful with renaming files. If you do a lot of renaming you'll most probable cause a lot of stress on the integrator. Remember, the RE integrate your CWS via diff and patch. Also, all restrictions of SVN regarding the renaming of files/directories still apply. If you plan to do a lot of renaming please do it on a SVN based repository. Or better, if possible, wait for the final switch to hg. * Tinderboxes, buildbots etc are currently adapted to Mercurial, some things might not yet work. Please contact me if you have problems, suggestions etc. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Mercurial-Implementation: automatic generation of outgoing repositories
Hi OOo Mercurial users, Automatic creation of outgoing repositories = The mechanism for the server side creation of the outgoing CWS repositories on hg.services.openoffice.org is in now place. An outgoing repository is automatically created for every CWS which is: a) flagged for Mercurial use b) in state new or later (but not for planned) It's no longer necessary to request Mercurial based CWSs per email. Any newly created mercurial based CWS should appear in this list no later than about two hours after the creation of the CWS: http://hg.services.openoffice.org/hg Fresh outgoing repositories will contain every milestone up to the creation milestone of the CWS, this ensures minimal network transfers consistent with the prevention of unnecessary heads. If the outgoing respository for your CWS is not properly created please notify me. Flag your CWS as mercurial (hg) based = It's possible to flag your CWS as hg based by editing the SCM entry in EIS. Starting with DEV300 m57 cws create accepts a new option --hg: $ cws create --hg DEV300 cwsname This will create a CWS with name cwsname in EIS with is by default flagged for Mercurial usage. Also it doesn't create these superfluous branches in SVN anymore. Please don't use this switch for OOO310 childworkspaces. Setting the current milestone of a CWS == Starting with DEV300 m57 the cws tool knows a new command: $ cws setcurrent -m milestone Use this to set the correct current milestone in EIS. You'll need this for hg based child workspaces because there is no wrapper (yet) to do this after a pull/merge. I'm currently thinking about how to set the current milestone automatically, but nothing is in place yet. You can set the master code line with this command as well, please use this prudently. - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Re: [tools-tinderbox] Any way to query mercurial to show me all changes on $tree since $date without creating a local clone?
Hi Christian,
this might not the smartest way to do it but one possible way would be:
1) setup a tree less clone of the master repository, which is kept
current via a cron job (once a day or so)
$ hg clone -U http://hg.services.openoffice.org/hg/DEV300 clean
2) cd clean
3) hg incoming --template '{date|shortdate}\n'
http://hg.services.openoffice.org/hg/cws/cws | tail -n 1
gives you the date of the last changeset added to the cws which is not
in the master (yet).
You might want to use the mercurial raw internal date for easier
comparison, you can do so by exchanging 3) to
3) hg incoming --template '{date}\n'
http://hg.services.openoffice.org/hg/cws/cws | tail -n 1
this gives you something like
1251109813.00
which is nicely monotone increasing with time :-)
If you detect a dirty tree, just do a
hg clone -U clean working
cd working
hg pull http://hg.services.openoffice.org/hg/cws/cws
[two heads now, tip is the last changeset of the CWS]
hg update -r tip
Hope this helps,
Heiner
Christian Lohmaier wrote:
Hi *,
To make tinderbox aware of mercurial based cws, there's one problem I
couldn't solve yet.
It isn't possible to query a remote repository for a log/changes.
You'd have to create a local clone.
This obviously is not an option for tinderbox, given the size of the
OOo repository and the amount of cws to deal with.
Querying the tip revision of a tree is as far as I could determine
that something has changed, but
* that only gives a new revision id
* and thus doesn't allow to poinpoint it the code to build has
changed at date, and hence it isn't possible to flag the trees as
dirty appropriately.[1]
* it isn't possible to show the changes in the commit-data view (what
files were affected by the changes)
So far I didn't come across a way to do a query like show me all
changes since $date (i.e. since last time I checked for changes)
(or after revision $revision)
The web-interface has a log-view, but the changeset selection is
reverse. i.e. when I pass a revision to let's say
http://hg.services.openoffice.org/hg/cws/writerfilter07/shortlog it
displays revisions going to the past from that revision, i.e. it only
shows changes up to the revision given, and not showing revisions
starting with the revision. (apart from that it is not really parsing
friendly - html files on one hand, but worse using 2 days ago and
similar instead of real dates, doesn't show the affected files wither)
So far, the Atom-feed is closest to a working solution (still cannot
tell the affected files directly, but could parse the changeset URLs
given in the feed
http://hg.services.openoffice.org/hg/cws/writerfilter07/rev/48c05ac131c35a0cc61ed74e78efa7d69de57e94
in raw-form
http://hg.services.openoffice.org/hg/cws/writerfilter07/raw-rev/48c05ac131c35a0cc61ed74e78efa7d69de57e94
But that is too verbose since it shows the actual diffs, and not only
the affected files (I'm not interested in the full diff of a rebase
for example)
(BTW: why does the Atom feed use the long-as-long-can-be revision-IDs?
rss feed/webpage itself uses the shorter form)
So: does anyone know a way to get something similar to
svn log --verbose --revision date/revision repo-URL
from mercurial without having to use local clones?
ciao
Christian
[1] dirty means: The build results are not valid anymore, since the
code has changed after the build has started. If you don't know when
the code did change, you cannot tell whether the build did start
before or after that change.
-
To unsubscribe, e-mail: tinderbox-unsubscr...@tools.openoffice.org
For additional commands, e-mail: tinderbox-h...@tools.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Re: [tools-tinderbox] Re: [tools-dev] Re: [tools-tinderbox] Any way to query mercurial to show me all changes on $tree since $date without creating a local clone?
Hi Christian,
Christian Lohmaier wrote:
Hi Heiner, *,
On Mon, Aug 24, 2009 at 3:34 PM, Jens-Heiner
Rechtienjens-heiner.recht...@sun.com wrote:
this might not the smartest way to do it but one possible way would be:
1) setup a tree less clone of the master repository, which is kept
current via a cron job (once a day or so)
$ hg clone -U http://hg.services.openoffice.org/hg/DEV300 clean
2) cd clean
3) hg incoming --template '{date|shortdate}\n'
http://hg.services.openoffice.org/hg/cws/cws | tail -n 1
gives you the date of the last changeset added to the cws which is not
in the master (yet).
You might want to use the mercurial raw internal date for easier
comparison, you can do so by exchanging 3) to
3) hg incoming --template '{date}\n'
http://hg.services.openoffice.org/hg/cws/cws | tail -n 1
this gives you something like
1251109813.00
which is nicely monotone increasing with time :-)
That is slightly better than using identify (that only gives the
revision), but still somewhat poor.
I'd really like to have the commit-message and the affected files
along with the date, to be able to create an overview just like with
svn:
in the status page:
http://tinderbox.go-oo.org/cmcfixes62/status.html
individual commits listed in the time-column all along with the build stati
and more details here (click a date on the status page and you'll jump
to the corresponding place in the vc-data page)
http://tinderbox.go-oo.org/cmcfixes62/all_vc.html
Oh, you can customize the output of incoming with the hg template
engine. Incredible flexible. Just have a look here:
http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html
I use this for example for creating the commit log messages for a hg
based CWS integrated via Subversion.
hg incoming --newest-first --template '{date|shortdate} {author|person}
{desc}\n' http://hg.services.openoffice.org/hg/cws/cws
What the svn page is lacking, is links to the actual diffs (but
currently there's no webserver that can provide specific revisions of
a file/show a diff between two given revisions for OOo's tree)
If you detect a dirty tree, just do a
hg clone -U clean working
cd working
hg pull http://hg.services.openoffice.org/hg/cws/cws
[two heads now, tip is the last changeset of the CWS]
hg update -r tip
Tinderbox doesn't build itself, so that's not needed, that's the job
of the buildslaves :-)
The pushlog (unfortunately not on OOo's version :-(() is very close to
what I want. (if it had the comments along with the filelist in a
single feed, that would be perfect)
We control the webinterface so I'm sure we can create something for you
if the above mentioned approach doesn't work.
Regards,
Heiner
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Re: [dev] Re: [tools-tinderbox] Moving to bost 1.3?
Hi Thorsten, Thorsten Behrens wrote: [Cc to tinderbox removed] Frank Schönheit - Sun Microsystems Germany wrote: As an additional note, it has been suggested to not commit the boost*.tar.gz to boost/download, but make it a pre-requisite which needs to be downloaded before building. This would (for 1.39) save 50M in the repository for every version ever committed there. Opinions on this plan are also welcome. Hi Frank, hm - in the light of heavy-weight commits like the .sdf one, ain't this just a micro-optimisation? Unless such stuff gets downloaded automagically, it's a big nuisance in the already-full-of-nuisances ooo build experience. Or invent a nice solution that does auto-downloads, and switch a few other huge external libs to that (like icu). ;) Actually, I would love that. Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] SVN commit hooks
Hi Jan, Jan Holesovsky wrote: Hi, Please, any chance to setup the hooks that disallow commits to already existing tags? ;-) OK, you convinced me, I've set up a hook which disallows any operation on tags other than add and remove ... and this for release engineers only. Anyone feeling himself/herself being release engineer enough to be allowed fiddling with tags please send me an email. I'll add you to the list. Regards, Heiner A commit to an existing tag just happened for the third time in the recent past (till the setup of the git mirror - it always breaks its update, so that's why I know about those), and it has never been a deliberate commit. Thank you, Kendy - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Please read: DSCMs, Mercurial Pilot and Performance
Hi Philipp, Philipp Lohmann wrote: Bjoern Michaelsen wrote: Oh sure, but you did that locally, and had no conflict. If you had a conflict when you did the pull/merge on Linux, manual intervention would be needed from you. On the server, I suppose just an admin would be allowed to solve that. No: on the server, you dont do any merges - you just create a new head/lightweight branch. Anyone can pull the heads and merge them (resolving conflicts) and push back(*). Which would make it unsuitable for integration. So how do I get rid of multiple heads on the server again ? Up to now I took the warning would create multiple heads as a queue, pulled and merged locally and then pushed. And that's the way we should handle it in the vast majority of cases. The documentation will contain an entry like never force a push to the outgoing repository (pull/merge into your working rep. instead). If you still do it, you are supposed to know how to get rid of the additional head in the outgoing rep without direct access to it. Regards, Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Please read: DSCMs, Mercurial Pilot and Performance
Hi Guido, I've checked this one out. Seems to be a consequence of the hg developers decision to only ever append to a revlog (hg's basic storage unit) and some other design decisions, Makes the storage quite stable I assume at the cost of space inefficiency. A pity I think. Heiner Guido Ostkamp wrote: Hi Heiner, Developers, please: if you make big changes like this, use svn move or it's equivalent to move the files, regardless if it's in SVN or later in a DSCM. We don't want to have hundred's of megabytes dead weights in a repository which every one needs to copy/clone many times.A I regret to say this, but even if you use 'move' Mercurial does handle this rather inefficient as you still get an additional full copy of the latest version. E.g. $ hg init $ cp /boot/vmlinuz . $ hg add vmlinuz $ hg commit -m checkin 1 $ du -s . 3120. $ hg mv vmlinuz vmlinuz.new $ hg commit -m checkin 2 $ du -s . 4644. $ hg mv vmlinuz.new vmlinuz.newer $ hg commit -m checkin 3 $ du -s . 6168. Obviously a lot of space is wasted with each 'move' although in the end you only have one file in your working tree. In theory only a few bytes would be needed to store a hint where the file came from earlier and then access that already existing store for further history. Git handles this much more efficiently: $ git init $ cp /boot/vmlinuz . $ git add vmlinuz $ git commit -m checkin 1 $ du -s . 3172. $ git mv vmlinuz vmlinuz.new $ git commit -m checkin 2 $ du -s . 3180. $ git mv vmlinuz.new vmlinuz.newer $ git commit -m checkin 3 $ du -s . 3188. This is how it should work. Maybe the OpenOffice.org project has enough influence to persuade the Mercurial developers to implement an improvement? Regards Guido - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Please read: DSCMs, Mercurial Pilot and Performance
Jan Holesovsky wrote: Hi Heiner, On Friday 24 of July 2009, Jens-Heiner Rechtien wrote: The whole changeset, converted to hg, blew up the OOo hg repository (store only) from 1.1 GB to 1.3 GB, or nearly 20%. This is interesting... The git mirror of the localization part of the SVN (localize.sdf's since the dawn of the OOo times + the l10n module when it was introduced) is still around 145M, even after the changes: If you converted from the SVN server than you will not have the sdf's since the dawn of Openoffice.org ... I took the liberty to only migrate the latest version of the sdf files to subversion :-) just as I did it with binary files. So all in all the numbers seem plausible. Still a bit more efficient than the hg ones. http://cgit.freedesktop.org/ooo-build/l10n I wonder, is there any chance to convert it to Mercurial (or construct the same thing in Mercurial) to see how big is would it be there? Probably about the same size (I'll check that out), but as Guido pointed out the numbers will rise faster for Mercurial than for git if people frequently move huge files around. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-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...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Please read: DSCMs, Mercurial Pilot and Performance
Hi developers, you might have notice, that pulling/merging/pushing a hg based CWS might be quite slow if the CWS was based on a pre-m51 milestone and you did pull a m51 or later milestone into the CWS. The effect is big enough to desire an explanation: In DEV300_m51 the CWS l10ncleanup04 has been integrated. In this CWS all the sdf files from all over the place have been move into a single module (top-level directory) called l10n. Now the sdf-files are a significant part of the overall OOo source tree (886 MB from a 2.0 GB total). This move of the sdf files also involved an additional change of format which prevented a simple use of svn move, the end effect being that the content was copied. This is not that tragic on a centralized system (server disk space being cheap) but is very suboptimal in a DSCM setting. Copying/Deleting/Adding the files prevented the svn-hg converter to recognize that something has been moved and be efficient about it, the old and the new files are unrelated as far as the SCM is concerned. The whole changeset, converted to hg, blew up the OOo hg repository (store only) from 1.1 GB to 1.3 GB, or nearly 20%. Thus we have now a single changeset in our OOo hg repository which represents nearly 20% of the size of the repository, the other 80% being the 262000 changesets which cover the trunk history of OOo since 2001. If you pull/push that changeset over the line it *will* take some time. Please bear that in mind if you judge the performance characteristics of hg. Developers, please: if you make big changes like this, use svn move or it's equivalent to move the files, regardless if it's in SVN or later in a DSCM. We don't want to have hundred's of megabytes dead weights in a repository which every one needs to copy/clone many times. I hastily add that I don't blame the author of the CWS for doing this, he hadn't much choice due to the (required) format change. But often we do have a choice, please keep this in mind. Thanks for your consideration Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: OOo Mercurial pilot
Hi Martin, Martin Hollmichel wrote: Jens-Heiner Rechtien wrote: Hi, time to start the OOo Mercurial pilot. Please find the details here: http://wiki.services.openoffice.org/wiki/Mercurial_Pilot unfortunately I didn't find any time yet to join the pilot, do I have still have some time to participate ? The way I see things you'll have plenty of time to participate :-) I'm currently preparing a call for comments on the pilot, will be out this week. I've got a lot of positive feedback already (and some criticism as well) so I'm optimistic about the overall outcome, but let's wait for the final result. If the participants of the pilot call it a success, we'll start the next phase - create all the bits and pieces of infrastructure necessary for the real thing. I will not urge the participants of the pilot to go back to Subversion during that time :-), they will still be able to do Mercurial CWSs and I hope they make use of it because I'll need their help in testing the infrastructure setup. In this phase we'll also be able to expand the number of hg hosted mercurials and involve more developers if they choose to participate. But anyhow, I have read only few comments about the pilot, maybe somebody from the participants can give a short summary about the status of the pilot ? No news is usually good news :-). Currently there are 16 hg hosted CWS open and one has been integrated. I had hoped that more CWSs are done and integrated at this time, but many of the mentioned CWS are still stuck in the QA cycle. Are there still any open issue we have to resolve (bonsai/cws query), do we need to do some more preparation for the transition ? We've got a *lot* of things still to do. EIS changes are needed, web servers need to be setup, server side clones need to be implemented, Bonsai, OpenGrok, build bots, tinderboxes etc. We'll be able to use some of the pilot experimental infrastructure for the real thing but there are many details still to be ironed out. Some stuff is optional and just nice to have, but some things are really essential. Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: OOo Mercurial pilot
Hi, trac is nice, no doubt. I think in the long run we'll support a number of source browsing methods, all with a slightly different angle. hgwebdir for changesets, opengrok for indexing and something like bonsai or parts of trac for diffing files/subtrees. I haven't yet sampled all the possibilities out there :-) Heiner Bjoern Michaelsen wrote: Christian Lohmaier cloph at openoffice.org writes: Is there bonsai for mercurial? I mean a system/frontend/website that at least allows you to query for show me the diff to revision foo of file bar from the previous revision show me all the changes on branch/directory foo since date really miss that one... Maybe trac? http://trac.edgewall.org/ We wouldnt need the other stuff provided by trac (wiki, issue tracking, ...) because we already have those, but the source browser and differ in trac is done rather well and is worth it alone. Have Fun, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] OOo Mercurial pilot
Hi, time to start the OOo Mercurial pilot. Please find the details here: http://wiki.services.openoffice.org/wiki/Mercurial_Pilot Regards, Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] DSCM - next step, start mercurial pilot
Hi Stefan, I would prefer hg.services.openoffice.org and not a generic one. We'll have to use at least svn and hg for a while in parallel and I would like to separate them completely. Heiner Stefan Taxhet wrote: Hi, I saw the discussion of the hostname in the comments. Do we want to go ahead with hg.services.openoffice.org or use something more general like source.s.ooo or src.s.ooo? Let's nail this down right from the beginning so that the svn.s.ooo isn't abused ;-) Greetings Stefan Jens-Heiner Rechtien wrote: Hi, I've been working on another project lately, but since this one is nearing finalization I'll have the time for the preparation of the Mercurial pilot RSN now. I'll announce the details here on the list. Some more details here: http://blogs.sun.com/GullFOSS/entry/mercurial_pilot_for_openoffice_org Heiner Martin Hollmichel wrote: Hi *, The ESC meeting agreed more than a year ago to migrate OpenOffice.org's version control from CVS via subversion towards an distributed source code managment (DSCM) system. The ESC is also in agreement that right now git and mercurial are both systems which are able to fulfil the requirements we have but there is no vast majority towards one of the systems. This is no real surprise since also other projects still don't show a clear favorite. The ESC also is in agreement that we should migrate now or in the very near future we can not afford to wait which system will win the race. Since the release engineering team is in favor of mercurial I ask - as the tools project lead - the RE team to start the pilot for mercurial now so that we will be able to have the new DSCM available with the 3.2 release. This is not an easy decision. But we had the choice, this was possible by the availability of the free, open source projects bzr, git and mercurial. Thanks to them and the teams that worked on the evaluation for an migration to OpenOffice.org. This is not a decision against one of them because of technical concerns, it is a pragmatic decision, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] DSCM - next step, start mercurial pilot
Hi, I've been working on another project lately, but since this one is nearing finalization I'll have the time for the preparation of the Mercurial pilot RSN now. I'll announce the details here on the list. Some more details here: http://blogs.sun.com/GullFOSS/entry/mercurial_pilot_for_openoffice_org Heiner Martin Hollmichel wrote: Hi *, The ESC meeting agreed more than a year ago to migrate OpenOffice.org's version control from CVS via subversion towards an distributed source code managment (DSCM) system. The ESC is also in agreement that right now git and mercurial are both systems which are able to fulfil the requirements we have but there is no vast majority towards one of the systems. This is no real surprise since also other projects still don't show a clear favorite. The ESC also is in agreement that we should migrate now or in the very near future we can not afford to wait which system will win the race. Since the release engineering team is in favor of mercurial I ask - as the tools project lead - the RE team to start the pilot for mercurial now so that we will be able to have the new DSCM available with the 3.2 release. This is not an easy decision. But we had the choice, this was possible by the availability of the free, open source projects bzr, git and mercurial. Thanks to them and the teams that worked on the evaluation for an migration to OpenOffice.org. This is not a decision against one of them because of technical concerns, it is a pragmatic decision, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] can't rebase to m42
Hi, that's most probably a bug in the m32 version of cws.pl. Please use the latest version from trunk. you'll find it in solenv/bin/cws.pl You should also use the latest version of Cws.pm which can be found in. solenv/bin/modules/Cws.pm Regards, Heiner lijian wrote: Hi all, Now I can't rebase my cws swcharunit02 from m32 to m42 which has just been migrated to svn from cvs. After commiting my changing ptach to m32, I re-downloaded my cws to local directory cws_charunit. when I cd to cws_charunit, and type svn info, it tells me that the working copy is cws swcharunit02. The info is as follows: Path: . URL: svn+ssh://s...@svn.services.openoffice.org/ooo/cws/swcharunit02 Repository Root: svn+ssh://s...@svn.services.openoffice.org/ooo Repository UUID: 8da58560-a4e7-4996-a0c2-a735b94b261c Revision: 268781 Node Kind: directory Schedule: normal Last Changed Author: lijian Last Changed Rev: 268781 Last Changed Date: 2009-03-04 14:31:23 +0800 (星期三, 04 三月 2009) But when I do cws rebase -m latest . in directory cws_charunit, it tells me that: ... verifying if workspace '.' is switched to CWS 'swcharunit02'. cws: ERROR: Your working copy '.' is not switched to the cws branch. Please fix and restart rebasing. FAILURE: cws aborted. The problem remains even I do svn switch ... in cws_charunit. Could anybody help me on this problem ? I am eager to know the answer to to problem. Thank you in advance. lijian 2009-03-05 -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Experimenting with CMake
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: Jussi Pakkanen wrote: Compared to dmake, CMake has the following advantages for OOo. - actively being developed - used widely and thus known by lots of people - native support for all major platforms and IDEs - cross-platform autoconf replacement - straightforward syntax, no shell magicks required (but you can use them if you want to) Other nice features can be found here: http://www.cmake.org/Wiki/Really_Cool_CMake_Features Actually, cmake has way to much features ;-) The key requirements for a build system for OOo is that it has: - few dependencies - portable - small - limited to the set of features absolutely needed (every additional feature is a lockin) While dmake might be obscure, it fits these requirements pretty well, and more is lost than gained IMHO by moving to CMake. CMake might have something going for it as a replacement for the mess that is autotools, however thats not an issue with OOo. If you would offer a migration path from dmake to plain GNU make and from tcsh to bash, that might be quite interesting ... Uhm, we've got no problem with bash anymore, everything should work fine with either tcsh and bash. If not, it's a bug ... Heiner [...] -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: [dev] Incompletely integrated cws
Hi, Rene Engelhard wrote: Christian Lohmaier wrote: How many other changes were lost while integrating other cws? How could this have happened in the first place? I mean I did understand that there were problems with deleted/added files, but in that case existing files were modified. Same with swffixes02 (which admittedly was a cvs based cws cloned) (I masterfixed it) CVS cloned CWSs are integrated by applying patches. It isn't that easy and especially in this round there were a number of problems, most of them caused by cross merges etc. The integrator in question was especially pleased by a CWS which deleted and added a few hundred files in a 3.0.1 CWS which had then to be cloned and integrated into DEV300. Restructuring work in OOO300 ... great. It's the price which has to be paid for RE relieving development by doing the clone integration stuff as opposed to require two CWSs for both major code lines. With 3.0.1 RC out of the door the number of CVS based and cloned over CWSs will be reduced a lot. So I ask you to bear with us for the moment. Getting this milestone out of the door before x-mas was quite a heroic effort. Heiner Regards, Rene - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] SVN and email notifications (resend)
Hi Frank, well, all this is scripting, so sure it's possible. What we would need is a set of mappings of top-level directories to projects. Well, to be exact four set of mappings, for example for svx .../trunk/*/svx- framework .../tags/*/svx - framework .../cws/*/svx - framework .../branches/*/svx - framework The initial setup is probably not a big problem but I hate the idea of maintaining such mappings forever. But if someone comes up with a good idea how to do this automated, I'll implement this. Heiner Frank Schönheit - Sun Microsystems Germany wrote: Hi Heiner, notifications to [EMAIL PROTECTED] should work now. any chance of breaking this down? In the past, I used the CVS mailing list to monitor commits to my project (to a certain degree, at least), and AFAIK others were doing this, too. allsvn, I suppose, will spam me with zillions of mails, and I'd like to avoid retrieving all those mails, just to delete nearly all of them immediately. I know that for SVN, the notion of project and module is meaningless, so anything to set up here is certainly non-trivial. Nonetheless, it would be useful to have some kind of subscription to a subset of allsvn. Any plans for this? Ciao Frank -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] ANNOUNCEMENT: OpenOffice.org migrates to Subversion
Takashi Ono wrote: In message [tools-dev] ANNOUNCEMENT: OpenOffice.org migrates to Subversion, Jens-Heiner Rechtien wrote... Also nothing has changed for OOo web content developers. The OOo web presence stays with CVS for now. Does that mean we cannot get logs or diffs through web any more for DEV300? Are there any plans for future implementation? The links will have to point to another server, but we'll have an OpenGrok implementation there which should do pretty much the same as the current implementation. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] ANNOUNCEMENT: OpenOffice.org migrates to Subversion
ANNOUNCEMENT: OpenOffice.org migrates to Subversion === The OOo subversion source code repository is now write enabled for all domain developers, thus we are officially migrated to Subversion. The details of the migration can be found here: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion Please note that old code lines up to the OOo 3.0 (including upcoming OOo-3.0.x microreleases) are still maintained with CVS. Also nothing has changed for OOo web content developers. The OOo web presence stays with CVS for now. Write access to the repository is organized via SSH public/private key pairs. If your public key is not yet migrated or you are a developer who used until now a shared tunnel to the CVS server, please have a look at these instructions: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#SSH_Setup Please allow a work day or two for your key to be enabled. If your key still doesn't work then, please contact me via email: [EMAIL PROTECTED] or IRC (nick: blauwal). With the migration we have updated our CWS-Tooling to cope with Subversion. There might still be bugs lurking there, so if you have trouble, please try to use the latest version: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#CWS_tooling Any problem reports, corrections and suggestions are welcome! Have fun Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] SVN and email notifications (resend)
Hi Stefan, Email notifications can be implemented with the post-commit hook. We'll implement that. Heiner Stefan Taxhet wrote: Hi, will we see email notifications of commits to the SVN repository? The list [EMAIL PROTECTED] is waiting for messages... ;-) Greetings Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] Migration to Subversion
MIGRATION TO SUBVERSION === The migrated OpenOffice.org SVN repository is now available via svn://svn.services.openoffice.org/ooo (read/only) or http://svn.services.openoffice.org/ooo (read/only) or svn+ssh://[EMAIL PROTECTED]/ooo (read/write) Please do refrain from committing to this repository for now (most ssh public keys aren't in place yet anyway) until RE announces the DEV300 m32 milestone with additional instructions. What you can do already with the repository: - test checkouts with the r/o access methods and all svn operations with the exception of commits - test if I got everything which is needed to build a DEV300 m31 milestone is included in the repository - build the DEV300 m31 milestone, please tell me if you found problems - start svnsync if you plan to have a local mirror (instructions on how to setup a mirror can be found here: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#Create_a_OOo_repository_mirror Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] OOo SVN migration
Hi, last weekend I managed to hurt myself with the kick starter of a bike and as a result I'm out of office for probably a week. This means that the Subversion migration will probably be delayed for a few days. Sorry for that. I keep you posted about when exactly we will do the migration. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Re: [council-esc] SVN migration status
Hi, I agree that getting rid of all (even potentially unsafe keys after the great ssh debacle) this way. Will require some administrative effort, though. Heiner Mathias Bauer wrote: Stefan Taxhet wrote: [cc'ed [EMAIL PROTECTED]; please follow-up there...] Hi, Nils Fuhrmann wrote: * server preparation: - migrate available keys from CN nach svn.services.openoffice.org: open, needs discussion with Stefan Heiner contacted me with this idea. My proposal was not to migrate 500 keys from the OOo main site. I recommended to contact the active code committers and ask for the key or a pointer to the relevant issue with the key attached. +1 for this. Let's get rid of keys that aren't used anymore. I would send a mail to the dev list of my project and assume that active contributors at least read this list regularly. We could also send mails to some other lists as well (dev, discuss, nl-lists...). In the worst case people that don't read any of these lists will ask us how to access the new repository. Ciao, Mathias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Hi Martin, I guess some additional documentation (about what the cwstools do and specifics of our setup) will be necessary. On the other hand we'll use pretty much subversion standard functionality and thus we can refer to the excellent Subversion documentation. Heiner Martin Hollmichel wrote: Heiner, will there be any additional tools or documentation necessary of will our cws tools will wrap this completly ? Martin Jens-Heiner Rechtien wrote: Hi, an updated repository acording to (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) is avaiable via: svn checkout svn://svn.services.openoffice.org/ooo/trunk or svn checkout svn+ssh://[EMAIL PROTECTED]/ooo/trunk for those who send me a ssh public key for the o3-build machine Heiner Jens-Heiner Rechtien wrote: Hi Guido, the migration is going nicely along. We do plan to migrate after the 3.0 RC. - We've got a box, a Sun Fire 4150 (8 cores, 64 GB RAM, no less). The URL will be svn.services.openoffice.org. An updated test repository will be on that machine RSN. - We'll use Subversion 1.5.1, that is with the build in merge tracking - The ESC council decided after some debate about the migration scope, aka how much history do we want (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) We will go along with option c) trunk only, this will also help with later DSCM options. I'll keep you posted here. Heiner Guido Ostkamp wrote: Hello, State of the OOo SCM project We plan to switch over to Subversion in the second half of July. the second half of July is nearly over and I haven't heard any news regarding the final switch to SVN since that discussion in early June. Is it going to happen? Regards Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Hi, an updated repository acording to (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) is avaiable via: svn checkout svn://svn.services.openoffice.org/ooo/trunk or svn checkout svn+ssh://[EMAIL PROTECTED]/ooo/trunk for those who send me a ssh public key for the o3-build machine Heiner Jens-Heiner Rechtien wrote: Hi Guido, the migration is going nicely along. We do plan to migrate after the 3.0 RC. - We've got a box, a Sun Fire 4150 (8 cores, 64 GB RAM, no less). The URL will be svn.services.openoffice.org. An updated test repository will be on that machine RSN. - We'll use Subversion 1.5.1, that is with the build in merge tracking - The ESC council decided after some debate about the migration scope, aka how much history do we want (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) We will go along with option c) trunk only, this will also help with later DSCM options. I'll keep you posted here. Heiner Guido Ostkamp wrote: Hello, State of the OOo SCM project We plan to switch over to Subversion in the second half of July. the second half of July is nearly over and I haven't heard any news regarding the final switch to SVN since that discussion in early June. Is it going to happen? Regards Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Hi, I'm currently playing around with Subversion 1.5 RC10 and have converted the repository to the 1.5 format. This means that currently access via http does not work which is no really a huge loss because it's not the fastest way either. I've no disk space for the old repository so it's gone. Guido, if you want access to this repository just send me your public key. Ian Clatworthy from the Bazaar team asked me to provide fast-svn-export style dumps and he mentioned that they have relevance for git as well so it might be worthwhile to start with them. I hope I'll get to create them next week. Heiner Jan Holesovsky wrote: Hi Guido, On Thursday 12 June 2008 00:46, Guido Ostkamp wrote: What concerns me a bit is the size of the repository - without actual trying, I have no idea how efficient git-svn will be on the full OOo import. Correct. We have to try that. Do you have an already converted local OOo SVN repo on your Git-box where this could be done? No, unfortunately not yet. If not, and you have access to an SVN repo elsewhere (e.g. on Heiner's servers) can you arrange a mirror of this (maybe SVK could be used for this?) so that later git tests can be run locally on your Git-box? Let me talk to our admins, how to get the box behind the company firewall etc. - might take a bit of time. If you can, please continue with the test locally - please, have a look at http://wiki.services.openoffice.org/wiki/SCM_Migration, according to the page, it should be enough to send Heiner your public key to be able to get a mirror of the SVN tree. Yes, this is a bit tricky, but I believe solvable ;-) In combination with 'svn lock', the 'pre-receive' and 'update' hooks would fail in case there are changes in the SVN CWS branch that are not yet merged in the git branch. You are right that this would be quite a limitation if the changes from SVN would not be mirrored too often; OTOH thanks to the OOo development cycle where just the release engineers can commit to trunk and others manage just the CWSes (branches), this would not be that much a problem for the CWSes created and managed exclusively in the git tree. Even if this would work, you will run into trouble with duplicated changesets. Remember, you push to Git first. Even if some mechanism automatically moves this into SVN as well, you still will have independent changesets in Git, and when running the next 'git-svn fetch' it will import the SVN changes again. But that have already been applied because Git changesets for this already exist. This will not work. Oh - I did not mean to setup this on top of git-svn, but rather a custom solution. The duplicate changes should not be a problem either, it is solved at least for the git - cvs - git roundtrip (see http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html), so I believe it should not be a problem for SVN either. Anyway - at some stage I'll try to come up with a proof-of-concept; either I'll see it is really a bad idea, or we'll have something to build upon ;-) Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Hi Guido, Guido Ostkamp wrote: Hello, On Mon, 9 Jun 2008, Jens-Heiner Rechtien wrote: As some of you might know, the OOo engineering steering committee (http://wiki.services.openoffice.org/wiki/ESC_minutes#SCM_review) decided that OOo will migrate to Subversion first but to reevaluate the big three DSCM systems (Bazaar, Mercurial and Git) within a year to account for new developments. well, when reading this I've mixed feelings. While branching with Subversion might be a lot easier compared to CVS, it still requires server access which free developers might not have. OTOH Subversion supports checking out partial trees. Free developers without Internet access? ... Well, maybe not all the time, right. :) I think there are conversion tools from Subversion to Git, Mercurial and Bazaar that allow to keep a DSCM repo in sync with a Subversion master repository at least one-way. I don't know how expensive this would be, but would it be possible to maintain a Git clone as a mirror that is synced with the Subversion repo on at least daily basis? I haven't looked into this conversion tools closely yet. If it's possible in a reasonable way I pretty sure we can and will offer something like that. Both systems are changeset based, Subversion keeps a bit more internal state than git, so yes, this could work. This would at least allow people to get the best of both worlds. Changes would of course have to be committed to Subversion. .../cws = place for CWSs Are you really going to migrate all old CWS that ever existed in CVS or are you skipping stuff that has been migrated to real versions? No, all integrated, closed or deleted CWS will be left out from the conversion. Saves us some 5000 branches :) Will the subversion repo cover just OOo 3.x or older versions as well? Older as well. Actually trunk and all releases should be covered. Will be a huge repository ... Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] Next OOOSCM meeting
Hi, please note that the next #oooscm IRC meeting on freenode next week has been moved from Friday to Thursday, 14th, 14 UTC. Thanks, Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOoSCM meeting tomorrow, new repositories on o3-build
Jan Holesovsky wrote: On Monday 03 December 2007 14:06, Jan Holesovsky wrote: the LGPL+SISSL-SISSL change producing tens of thousands of commits.) The Doh, LGPL+SISSL-LGPL of course ;-) A LGPL+SISSL-SISSL change might not need tens of thousands commits but it certainly would produce tens of thousands comments :) Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] OOoSCM meeting tomorrow, new repositories on o3-build
Hi, in preparation for our next meeting I've installed two very simple minded bazaar and git repositories on o3-build.services.openoffice.org. In both cases I've imported only the OOo-2.3.0 source code^1, thus no history at all. I'm still not able to make a sensible import in either bazaar or git, I could need some help here. John, Jan were you able to do imports with a comparable history as the subversion repository on o3-build? I would gladly place them on o3-build for some real comparisions. Nevertheless even the imports without history could give us some insights about certain characteristics (performance and otherwise) of the repositories. The repositories are accesible via http and git/sftp: Bazaar: --- bzr branch http://o3-build.services.openoffice.org/~svn/bzr/trunk tr.dev or bzr branch sftp://o3-build.services.openoffice.org/~svn/bzr/trunk tr.dev for sftp access I need to reconfigure your .ssh key (would disable svn+ssh support). Please send me a note if you wish bazaar via sftp access. Git: git clone http://o3-build.services.openoffice.org/~svn/git/ooo230.git or git clone git://o3-build.services.openoffice.org/~svn/git/ooo230.git I've played around a bit with the bazaar branch vs. checkout resp. checkout --lightweight feature. I do very much like that it is possible with bazaar to mix freely between centralized repositories for our small teams and full local repositories for our nomadic developers. Best of both worlds here. Is there a similar functionality in git? Heiner Notes: ^1: checked out from the svn server with: svn export svn+ssh://[EMAIL PROTECTED]/svn/tags/OpenOffice_2_3_0 -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] OOoSCM IRC Meeting
Hi, the next OOoSCM IRC meeting will be on Friday, 23rd 14 UTC (channel #oooscm, freenode.net) Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOoSCM IRC Meeting, Minutes
Hi, I did some trial checkouts over my 4MBit Home-DSL Line and found that there are extreme differences between the checkout times via the http and svn+ssh protocols. http: 3h 50min svn+ssh: 20min Even if we account for different server loads etc etc it looks like using http even for ro checkouts is not a good idea. I've no idea why it's so bad, I'm still looking into it. As a consequence I will setup readonly access via svn as well (without ssh key). Anyone attempting to use svnsync to mirror the server should use the svn protocol. Heiner Jan Holesovsky wrote: Hi Heiner, On Monday 19 November 2007 14:23, Jens-Heiner Rechtien wrote: I tried to svnsync the repository over http. The results were quite disappointing, after about one hour runtime, I had only fetched 17 (yes, seventeen) changesets. As far as I can see the repository contains over 50 changesets. During that time, I had always plenty of CPU% available and the network (DSL-2000) also had a lot of capacity left. After one hour I decided to stopped it. My local repo with the 17 changesets now has a 'du -k' size of 69356. Do you have an explanation for this bad behaviour? The first 20 or so changesets contains extraordinarily much stuff, as it represents they first complete import in CVS in 2000. That said, the repository is still huge. It's probably bigger than necessary, but a real repository will grow anyway. 69 MBytes in one hour over DSL2000 is not good enough (no matter which SCM we choose). I'll check if the apache2 on the server might be the bottleneck. So far, my svn synchronization which I started on Friday is at about revision 117000 (it failed over the weekend, and I restarted it today in the morning); so does not look too optimistic either :-( [It's over a faster line than DSL]. Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOoSCM IRC Meeting, Minutes
Guido Ostkamp wrote: Hello Jens, the SCM Migration Wiki page contains now additional instructions on how to replicate the SVN repository, for example as a local mirror. I tried to svnsync the repository over http. The results were quite disappointing, after about one hour runtime, I had only fetched 17 (yes, seventeen) changesets. As far as I can see the repository contains over 50 changesets. During that time, I had always plenty of CPU% available and the network (DSL-2000) also had a lot of capacity left. After one hour I decided to stopped it. My local repo with the 17 changesets now has a 'du -k' size of 69356. Do you have an explanation for this bad behaviour? The first 20 or so changesets contains extraordinarily much stuff, as it represents they first complete import in CVS in 2000. That said, the repository is still huge. It's probably bigger than necessary, but a real repository will grow anyway. 69 MBytes in one hour over DSL2000 is not good enough (no matter which SCM we choose). I'll check if the apache2 on the server might be the bottleneck. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOoSCM IRC Meeting, Minutes
Hi Jan, the SCM Migration Wiki page contains now additional instructions on how to replicate the SVN repository, for example as a local mirror. Heiner Jens-Heiner Rechtien wrote: Hi Jan, I've put access instructions on the bottom of the SCM Migration Wiki page: http://wiki.services.openoffice.org/mwiki/index.php?title=SCM_Migration It's possible to access the repository anonymous (ro) and via ssh (rw). Please be aware that I'll exchange the content of this repository tonight with a more complete import (freeze date 2007/10/30). It's possible to mirror this repository via svnsync. I'll place instructions on how to do together with the access instructions, as soon as I figure them out. As for this week's meeting: unfortunately I will not be available the whole day on Friday so moving it to 12:00 UTC will not ensure that everyone involved is available :). Martin will be the stand-in for me. I suggest that we keep the date/time since it's supposed to be a regular public meeting and moving the date/time will only spread confusion. Shouldn't be much of a problem if we both are missing this week, I suppose, given that we've got a plan on how to proceed. If something urgent comes up we can still discuss it on this mailing list or the regular developer IRC channel. Heiner Jan Holesovsky wrote: Hi Heiner, On Monday 12 November 2007 17:24, Jens-Heiner Rechtien wrote: Please find the minutes of the OOoSCM IRC Meeting (Friday 2007/11/09, 14 UTC) here: http://wiki.services.openoffice.org/wiki/OOoSCM_Minutes Thank you! Please, are there the instructions how to checkout your SVN import somewhere? Is it possible to mirror it somehow so that I could try to do the direct SVN - Git locally? One more thing: Could we please move this week's meeting to 12:00 UTC? I am very sorry, but I won't be able to attend it at 14 :-( Regards, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOoSCM IRC Meeting, Minutes
Hi Guido, the plan is to have a number of comparable repositories on this server, and this includes at least svn, git, bazaar and maybe, if possible, Mercurial. Heiner Guido Ostkamp wrote: On Wed, 14 Nov 2007, Jens-Heiner Rechtien wrote: I've put access instructions on the bottom of the SCM Migration Wiki page: http://wiki.services.openoffice.org/mwiki/index.php?title=SCM_Migration It's possible to access the repository anonymous (ro) and via ssh (rw). Please be aware that I'll exchange the content of this repository tonight with a more complete import (freeze date 2007/10/30). will you also provide an updated Git repository? Regards Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] OOoSCM IRC Meeting, Minutes
Please find the minutes of the OOoSCM IRC Meeting (Friday 2007/11/09, 14 UTC) here: http://wiki.services.openoffice.org/wiki/OOoSCM_Minutes Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Git / SVN Source code repositories
Martin Hollmichel wrote: Guido Ostkamp wrote: I also wonder why you are not looking at Mercurial yet (http://www.selenic.com/mercurial/wiki). It has been selected by a number of projects, e.g. OpenSolaris and Mozilla. The concept how branches are implemented with Mercurial doesn't fit that good in OpenOffice.org Developmemnt Model. Since OOo Feature Development happens on branches in teams and thus branches should be shareable by all, Mercurial doesn't seems to be the natural choice since there branches are done in distributed manner. This was true when we evaluated Mercurial around March. Now Mercurial has support for named branches inside a repository, which at least theoretically would fit the bill. I'm not sure how well they would work in our case, the support for named branches is quite new in Mercurial and I haven't come around to try it out. It seems that all DSCMs are very actively developed currently, which makes a final evaluation a bit difficult. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] checking out all of OOo 2.3.0 sources ???
Simon Brouwer wrote: Hi Joost, Rene, On wo, 2007-10-31 at 09:52 +0100, Joost Andrae wrote: Hi Simon, the release branch for 2.3.0 is OOG680 and the CVS tag for 2.3.0 is OOG680_m5 as described within the release notes Thanks! I got the information about the ooo230 tag from http://wiki.services.openoffice.org/wiki/Cvs_tags_and_branches What is that about then? the ooo230 tag is used for QA stuff I think. The official tag for the OOo 2.3.0 sources is OpenOffice_2_3_0, which is kinda an alias for OOG680_m5 which is the milestone on which OOo 2.3.0 has been released. There is also a branch called mws_oog680, which contains all the changes made when stabilizing the tree for OOo 2.3.0 and also contains the upcoming fixes for OOo-2.3.1. The web-page is a bit wrong, we'll correct that. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] build times, HelpLinking ?
Rene Engelhard wrote: Am Dienstag, 29. August 2006 18:09 schrieb Jens-Heiner Rechtien: ... and the other gigantic elephant is officecfg. Both projects scale linearly with the number of enabled languages - ouch. Of course, most developers (old hands or new ones alike) will probably build only one or two languages, if they are not involved in localization issues, so the ... or distro packagers ;-) elephant might not look that big as an entrance barrier. For everyone who has the need to build more languages these two projects are just a choose your expletive, of course. officecfg is far faster than HelpLinker, especially if you use xsltproc ;-) Hey guys, I'm currently trying to talk someone into accepting the xsltproc approach, so that's why I'm always repeating that officecfg is dog slow :-) But even with xsltproc it's no fun with 69 or so languages. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] build times, HelpLinking ?
Hi Caolan, ... and the other gigantic elephant is officecfg. Both projects scale linearly with the number of enabled languages - ouch. Of course, most developers (old hands or new ones alike) will probably build only one or two languages, if they are not involved in localization issues, so the elephant might not look that big as an entrance barrier. For everyone who has the need to build more languages these two projects are just a choose your expletive, of course. Heiner Caolan McNamara wrote: With all the build times talk going around, no one seems to have mentioned the obvious gigantic elephant in the room (for extern devs anyway), i.e. building helpcontent2 takes a huge amount of time. i.e. when building for 61 languages (and approx 42 of them with help content) with build -P2 -- -P2 on a RedHat buildbox (through gcj) my times for the full build... build start time is Mon Aug 28 06:44:07 build end time is Mon Aug 28 12:00:23 and while I don't have times to hand for just helpcontent2 on it's own to get the percentage of total time involved, from experience HelpLinking takes an awesome amount of time. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] Re: jam01 - first impressions
implementation has to make sure that the used cimpiler options match). while doing so, i noticed that the current jam prototype doesn't care too much about compile switches and the PCH implementation is broken by concept :(. so the resulting output of the current jam build are good for measurement at best. using the broken PCH implementation (may be fixable for the majority of object files but add yet another bit of complexity, regardless if jam or dmake) for measurement, the times went down a bit more: 47m17s - dmake with hacked PCH taking into account that jam doesn't compile with optimization and restricting the dmake build to the targets a pure jam build is able to do, i got: 40m50s - almost compareable dmake build this build is still not using batched compiling which will give yet another speedup... regarding reduced complexity, my current impression is that the jam build system is somehow over simplified to a degree where the output is unusable without major rewrite. the whole gathering of compiler switches and defines boils down to an almost static compiler line. the PCH usage doesn't care if the precompiled files are compiled with the same options, thus producing inconsistently compiled object files. this of cause gives real simple Jamfiles and also a bit of speedup. i'm still fighting, not to compare apples with oranges but my current feeling is that using jam instead of build/dmake will give a speedup of 10-20 percent at best. tschau... ause -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] ICC compiler...
Hi Ken, ICC here means an old OS/2 compiler. It's obsolete, for sure. Now if someone comes up with an Intel compiler port the macro might get reused, so we better clean up ... Heiner Ken Foskey wrote: ICC is not set in configure. Can I assume that ICC compiler is redundant for S/O as well.. .IF $(COM)==ICC CDEFS+=-D_STD_NO_NAMESPACE -D_VOS_NO_NAMESPACE -D_UNO_NO_NAMESPACE .ENDIF -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] where can I get the CWS tool modules?
Hi Lesley, the CWS tools are a bunch of scripts to enable developers to work on an isolated branch and ease the reintegration of these changes into the main codelines. They are not needed for bug fixes by non-committers, in this case just attach a patch to an issue. Note that before we can consider contributions, the author needs to sign the joint copyright agreement (JCA). Heiner Lesley Zhang wrote: Hi, Heiner, I think it's useful for us to fix the bugs for OpenOffice. This is my first time to hear about CWS, I don't know if it is fit for my purpose. Could you give some advise please? thanks a lot! yours, Lesley ÔÚ2005Äê05ÔÂ11ÈÕµÄ18:19£¬Jens-Heiner RechtienдµÀ£º Hi Lesley, you'll get module solenv if you check out the OpenOffice source from the OOo CVS server. Once you have configured your OOo workspace the CWS tools are available to you. May I ask for what purpose you need the CWS tools? They are only really useful for 'committers'. Heiner Lesley Zhang wrote: should I install the solenv module first? I find this module on OpenOffice.org, but I can't obtain it. what should I do? thanks!:) ÔÚ2005Äê05ÔÂ11ÈÕµÄ17:30£¬Jens-Heiner RechtienдµÀ£º Hi Lesley, the CWS tooling is located in module solenv: solenv/bin and solenv/bin/modules. Heiner Lesley Zhang wrote: I wanna use it under Linux Cinnabar on x86. How can I get these tools? thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Re: Can OOo for windows be built without VStudio?
Curtis Clauson wrote: Jens-Heiner Rechtien wrote: Curtis Clauson wrote: [EMAIL PROTECTED] wrote: Hi Curtis, Curtis Clauson zei: Pavel Janík wrote: From: Curtis Clauson [EMAIL PROTECTED] Date: Sun, 30 Jan 2005 03:49:04 -0800 Can OOo for windows be built with GNU compilers in Cygwin instead of using MS Visual Studio? It seems like it should, but all of the build docs only talk about MSVS. Anyone got an answer for this? See http://www.openoffice.org/issues/show_bug.cgi?id=24588 Fascinating! - and disturbing. I had no idea open source OOo had components that depended on a commercial distribution. Why disturbing? After all, even to *run* OOo for Windows you need closed-source commercial software (i.e. Windows). The ability to build and run OOo using all-free software under Linux demonstrates that OOo is not dependent on a commercial distribution. Vriendelijke groet, Simon Brouwer -- nl.openoffice.org -- Open Source multi-platform projects have always striven to at least build with non-commercial components on any platform, commercial or not. It is not part of the technical definition of Open Source, but has always been a primary goal. I've some - umpf about 15 years - experience with OpenSource and no, this was certainly not a primary goal all the time. It's nice when it's possible but the primary goal was mostly to get the stuff build with the major tool chain on that platform, be it commercial or not. Cygwin and mingw are quite recent additions to the gcc platforms. The StarOffice/OpenOffice code base was around for years before cygwin/mingw became a viable alternative to the Visual Studio (and if you ask the OOo developers the majority of them will assert that at least the Visual Studio debugger is still far superior than gdb) Yes, I know what you mean. Having worked with various open source projects for almost 30 years I've accepted that there are always people who try to deny or erase the history of open development tools on Windows simply because it's a MS platform. However, as much as I love Linux, since Windows is still the most common end-user OS, the need for open builds is still as important. This allows users of a commercial OS to build the project without any other product purchase. Many institutions, like schools and NPOs, can only use whatever OS was donated to them or is useful in their vocational training. They must rely on GNU tools for their builds. Remember it's 'free' as in speech not 'free' as in beer. If these instutions can't afford a commercial compiler they shouldn't use a commercial platform like Windows. Linux is better suited if they are cash strapped. BTW, this is a bogus argument because as far as I can see pratically no one in shools or NGO's will ever build OpenOffice for themselves. It's a daunting experience and only very few people are able and and willing to do the build on Windows, and I bet almost all of them are reading this list :-) Volker and some others have worked very hard to make the build experience a bit more pleasant but it remains a huge pile of unwieldy source code and no amount of work will change that. Heiner This is why I alway politely ask first rather than throw terms like bogus around. This question was brought to me by a group of high school students. Their school uses donated equipment that came with Windows, and Linux is of no use in their vocational studies since Linux is mostly used on the server side and not in office environments. These students thought that some work on the OOo project would do nicely for a school exhibit at the County Fair science hall on the benefits of Open Source to the general community. I didn't meant to offend someone. Sorry if I came over a bit to brusk. It's just that porting OpenOffice to mingw is such a major task and while people do see the benefit it's really a question if such a port is really used often enough to make the effort worthwhile. It's not just the one time port, though. This is a 11.5 million lines beast and you have to maintain the port in an ongoing manner to keep it viable. It's not that we didn't investigate such a port. Vladimir Glazounov of StarOffice/OpenOffice release engineering has donated quite a bit of time and others, too. Finally it always comes down to this: If there is someone to do and maintain the port then there will be such a port. If not, well, then not. Well, it's OpenSource, isn't it? Release engineering will, as usual, accept patches if they don't endanger the other platforms. We (that is, StarOffice/OpenOffice release engineering) did a similiar port once for gcc on Solaris. It has gone stale because of a serious lack of interest. Just to give you a short overview what it would take to do the port: You've got to compile the 95% of OOo which is identical on all platforms. That's easy because we use gcc on Linux x86, Linux Sparc, Linux PPC, FreeBSD, NetBSD, MacOSX etc in no particular order
