geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <>
Subject Re: SVK
Date Tue, 05 Dec 2006 15:16:03 GMT
Good info--Thanks Jason

Jason Dillon wrote:
> Yes, this is the best way... merge from 1.2 to trunk, as *most* of those 
> changes will be fairly simple to apply, and automatic with SVK (well, up 
> until the point when we rearrange trunk, but until then).
> But some minor changes may also need to go the other way.  SVK should be 
> able to handle this.  When I was working with SVK for the m2 migration 
> branch, I was keeping all svn notifications I got, then when they 
> buffered up enough, I would use SVK to merge each change, limiting the 
> path to either file or src/main/java for the modules affected to avoid 
> pulling in unwanted changes.  In the case of the m2 migration, unwanted 
> changes would be stuff in a pom.  You could do a merge from the branch 
> root, then cherry pick the changes, but that is not much fun when there 
> are a bunch of changes.
> Anyways... IMO its best to try to only merge from 1.2 to trunk, and if 
> needed only merge from trunk to 1.2 on a per-file basis.
> That means if you are working on fixing a bug, its best to fix it in 
> 1.2.  But experience has shown that people will work off of trunk and 
> merge into branches more often than desired.  But, if you are careful 
> about the merge then no major problems should pop up.
> I also recommend, when using svk smerge, that you first run with -C to 
> see what it wants to do first.  Limit the changes pulled in to one merge 
> if possible to avoid picking up something you did not want.
> And when you do the merge, use the -I flag to include the original text 
> of the commit into the merge automatically, this makes it easier to 
> track... and more automated... as if there are not conflicts, the merge 
> will not require any user interaction.
> When you initially setup the svk config you will need to use --baseless 
> on the first smerge, but only for the first... all afterwards SVK should 
> have enough details to find the base, not sure what will happen if you 
> keep using --baseless, so I don't recommend it.
> And if you run into anything strange, unlikely but might happen, hope in 
> #svk on freenode and ask, they have been very helpful to me.
> --jason
> On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote:
>> Ok, I'm setting up SVK so that we can keep changes between the new 1.2 
>> Branch and Trunk in sync. I don't mean to be too simplistic but I 
>> would like to verify these assumptions on my part are correct (before 
>> I do anything untoward):
>> 1. The primary intent will be to ensure that changes made in the 1.2 
>> Branch will get merged into Trunk. Ideally these will be fixes and/or 
>> enhancements that have been made to the 1.2 Branch that must also be 
>> ported into Trunk as well.
>> 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This 
>> should pretty much be business as usual (it would be very difficult to 
>> try to identify just code fixes in Trunk that have to be retrofitted 
>> back into the 1.2 Branch).
>> This seem reasonable to everyone ??
>> Thanks much
>> Tim

View raw message