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. Dan 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) 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
