incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <Mathias_Ba...@gmx.net>
Subject Re: [Repo] SVN ETA?
Date Wed, 10 Aug 2011 18:13:24 GMT
On 10.08.2011 19:29, Eike Rathke wrote:

> Hi Mathias,
> 
> On Wednesday, 2011-08-10 13:45:43 +0200, Mathias Bauer wrote:
> 
>> Sooner or later each cws will be either integrated into the main code
>> line of it will be discarded in case we don't consider it worth an
>> integration. I maintain my proposal to treat each cws in the following way:
>> 
>> - review its content
>> - rebase it to the tip of the trunk repo (OOO340m1)
>> - create a list of change sets that are not in OOO340m1
>> - convert each changeset into a patch
>> - create an svn branch from the svn tag corresponding to OOO340m1
>> - apply all patches one after another
>> - merge with svn tip
>> 
>> In case the cws contains merge commits, we can avoid them by re-applying
>> all other patches to a OOO340m1 code line, adjusting the code in case
>> the patch does not apply correctly and create new patches (very much the
>> same way as you would do with mq-patches).
> 
> I don't know if there's anything like SVN queue or something to ease the
> patch set handling. In case there isn't I'd recommend to work with git
> svn (I would recommend that anyway for everything ;-) on trunk, and on
> the local git repo use stgit with imported patches from each cws.
> 
> Workflow for each cws:
> * convert each changeset not in OOO340m1 into a patch and feed it to stg
>   import, massage until applies cleanly
> * when all patches are in stgit, do stg commit --all
> * git svn rebase, solve merge conflicts
> * git svn dcommit
> * continue with next cws
> 
> The advantages I see in this approach over the pure svn handling:
> * everything happens locally until a rebase or the final dcommit (work
>   from everywhere ;-)
> * no intermediate branches needed, smaller resulting svn repo
> * work can be distributed among several people, each one cws, each
>   working on the then current tip instead of OOO340m1
> * rebases and merge conflicts can be solved early against tip while
>   still working on a cws if one knows a cws touches the same area of
>   code as an already integrated one:
>   * stg pop --all
>   * git svn rebase
>   * stg push --all
>   (this usually is done with
>   git update remote; stg rebase remotes/origin/master
>   it may work with
>   git svn fetch; stg rebase remotes/git-svn/master
>   as well, to be tried)

Sounds interesting, but it's too much to digest for the moment. :-)
Fortunately we have time to think about that or even try it out, getting
the trunk repo to Apache is more urgent.

If noone thinks that hg convert can cope with merge change sets, we know
that only the OOO340m1 tip can be imported as a first step.

Regards,
Mathias

Mime
View raw message