geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: SVK
Date Wed, 06 Dec 2006 21:43:37 GMT
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