cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: DoMerges updates....
Date Fri, 17 Feb 2012 11:43:47 GMT
Hi Dan,

It's a great news, with the help of git I don't have to wait merge 
command for minutes.

Cheers,

Willem

On 2/17/12 1:23 AM, Daniel Kulp wrote:
>
> A couple of you have noticed a flurry of updates to my little DoMerges script
> thingy.  I'm still tweaking it a bit, but it seems to be in a fairly usable
> state now so I thought I'd mention the changes.
>
> Major changes:
>
> 1) No longer requires (or even uses) svnmerge.py.  It now uses the svn
> executable directly.  Thus, windows folks don't need python or any other wacky
> things installed.   However, it records the blocks and merged things in the
> exact same way as svnmerge.py so it's completely compatible.  You can use
> DoMerges or svnmerge.py, flip back and forth, etc...
>
> 2) Now supports a git clone and uses "git cherry-pick" - this is the big one
> for me.   You don't need to have a svn checkout for each branch and such.  If
> you have a git clone with a branch tracking the appropriate apache branch,
> DoMerges will now use git cherry-pick and git commit to handle the merging.
> For the merges from trunk ->  2.6, this can help a LOT.  A lot of classes have
> moved from module to module on 2.6.  svn merge does a crappy job handling
> changes in files that have moved and generally just registers a conflict.
> git cherry-pick works much better and generally merges the changes into the
> old locations just fine.
>
> HOWEVER, git svn doesn't support setting of svn properties.  (it can get
> properties, but not set them).   Thus, to record the stuff that has been
> merged, it needs to do a final svn checkout, set the properties, then a
> commit.   (in another bizzare thing, you can do an "svn propedit" on an https
> url and interactively edit a property in an editor, but you cannot "svn
> propset" a url based thing.  Thus, the checkout is needed.)   Thus, using the
> git stuff will involve an extra "recording" commit at the end.   However, this
> really isn't any different than when Colm or someone does a manual git cherry-
> pick and I record them later.
>
> Anyway, the main thing for me was to try and make the merges from trunk/2.6 ->
> 2.5 as easy as possible.   A bunch of the bugs I've fixed lately are in
> classes that have moved so having a quick and easy way to merge  those fixes
> was important to me.   git helps with that.    The removal of the dependency
> on the python script is just an added benefit.   :-)
>
>


Mime
View raw message