incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <>
Subject Re: A point on the OOo code
Date Fri, 19 Aug 2011 12:22:28 GMT
On 19.08.2011 08:21, eric b wrote:

> Hi,
> My starting point was : I'm used to the OOo source code, but I do not  
> know how to retrieve an old cws. In fact, I don't know at all what do ..
> We suppose that I currently got an hg blob, containing until  
> DEV300_m93 (which is sufficient for my needs / tests). Add that I  
> know how to extract a milestone, compile it, and create diffs.
> Q1 : is it possible to explain a dummy like me :
> - how to download the current code (the OOo milestone we'll take as  
> starting point), using svn  (only the instruction with the right URL  
> is ok for me)
> Note : even if the tree is not complete, but what is the command, or  
> what will be the command  ?
> Q2 : how to connect the hg code to the svn one ?
> Q3 : how to retrieve an old cws and extract the diff ?  I read the  
> wiki, and found nothing usefull on the mercurial side, and be able to  
> retrieve something in the history is essential.

I would wait until the first svn import is done and the source can be
retrieved via svn.

Working with cws is possible in several ways, my plan to bring my
existing cws to Apache is as follows:

I use the cws hg repo I still have on my hard disk (I hope that we soon
can move them all to Apache-extras). If possible, I will try to convert
the cws commits (get a list of them by using "hg outgoing" against a
trunk repo) into an "mq" patch queue. If that fails because I already
had merge commits in my cws, I will just take all other change sets,
create diffs from them using "hg diff -c" and take these as patch queue.

Then I try to apply all patches manually to an OOO340_m1 branch,
eventually adjusting the change sets in case of conflicts. The result
should be a patch queue that - when applied to OOO340_m1 - gives what
the cws contained. This will require some code reviewing and testing
after applying each patch, but IMHO we have to review the existing cws
anyway so that this isn't much more work than necessary.

Now I can create a new svn branch, apply the patches one by one (this
way I preserve the full cws history in svn!) and do the merge in svn
once the branch/cws is considered worth an integration.


View raw message