incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eike Rathke <...@erack.de>
Subject Re: [Repo] SVN ETA?
Date Wed, 10 Aug 2011 17:29:56 GMT
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)


  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Mime
View raw message