geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <tim.mcco...@gmail.com>
Subject Re: SVK
Date Sun, 10 Dec 2006 18:39:19 GMT
Got it--thanks much

Tim

Jason Dillon wrote:
> I'm not sure what you mean... you are seeing diffs or conflicts?  
> Normally svk will handle trivial diffs like this... so while it will 
> show up as a difference, there is no conflict, smerge should be able to 
> resolve this with no user interaction.
> 
> Or do you mean something else?
> 
> --jason
> 
> 
> On Dec 5, 2006, at 6:26 PM, Tim McConnell wrote:
> 
>> Jason, since you've done this before make you can help me understand 
>> to what degree we should strive to keep these files in sync. I notice 
>> that many of the differences between Trunk and the new 1.2 Branch are 
>> related to omissions of $Rev and $Date in various java, js, jsp, and 
>> properties files. Are these entries being added automatically by 
>> either SVN or an IDE, and should we bother syncing files with only 
>> these differences ?? Thanks
>>
>> Tim
>>
>> 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
> 
> 

Mime
View raw message