cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject DoMerges updates....
Date Thu, 16 Feb 2012 17:23:03 GMT

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.   :-)


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message