cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: DoMerges updates....
Date Thu, 16 Feb 2012 17:56:55 GMT

One more thing:

3) If you want to just consider a single version, you can do:

java DoMerges 1245077

or similar and it will just check that one version.


On Thursday, February 16, 2012 12:23:03 PM 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)  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 so it's completely compatible.  You
> can use DoMerges or, 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.   :-)
Daniel Kulp -
Talend Community Coder -

View raw message