[infinispan-dev] porting from 4.1.x to trunk

[Mircea Markus]

On 1 Jul 2010, at 19:08, Manik Surtani wrote:

> 
> On 1 Jul 2010, at 16:09, Mircea Markus wrote:
> 
>> Hi,
>> 
>> I've just finished merging everything from 4.1.x to trunk, so trunk does contain latest and greatest from 4.1.x branch(r1875 through r1949)
>> 
>> Few thoughts on porting from 4.1.x and trunk:
>> - right now we use two approaches: one is to port each change in two places or to do a single merge/port  before a release to contain all changes.
>> As per today's experience this doesn't work: Manik wanted to check into trunk a fix  that depends on some code of mine, not yet  ported: bang!
>> 
>> Both options have pros and cons.
>> My option is for doing larger grained merges, and here is why:
>> - simpler development process. With the former one need to do this additional work for each task:
>>     - svn update on trunk
>> 	- copy (or svn merge) from 4.1.x to trunk
>>    - mvn test on trunk, on the affected modules
>>    - commit
>> Perhaps not a lot, but this needs to be done (virtually) on each commit. Otherwise people that rely on the changes will have problems while migrating theirs. 
>> - a single SVN history (at the moment there are two of them).
> 
> Well, given the stage we are at in the 4.1.x dev process (primarily bug fixes == deltas of a few lines at a time for each fix) I don't see this as a massive overhead.  For example, what I tend to do is:
> 
> 1) Fix on 4.1.x.
> 2) Diff the affected classes against trunk (usually a few lines per class.  Remember, small change-sets are good.)
> 3) Merge in the changes (IntelliJ offers a nice GUI to help with this, usually takes me < 2 mins extra per commit)
> 4) Test both trunk and the branch.  Hudson is your friend.
> 
>> The main cons is the conflict resolution. The longer you delay the integration, the more difficult it is to solve conflicts. 
>> I don't think this is such a big issue: our code is quite clean, no big classes, no large methods, very modular project structure. We also have a test suite to run, which can give us confidence on the result of the merge.     
> 
> Yes, but unfortunately I think this chews up time.  Merging a bunch of un-connected changes is always much harder (how long did it take you to merge the last couple of weeks of your work alone, definitely measured in hours?) and especially when you are not responsible for all of the changes.  I.e., how do you resolve a conflict?  Can you even remember the details of why a change was made, 2 weeks later?  How do you deal with this when the change involves something someone else has done?  Conflicting changes which you were not a part of?  
> 
>> I volunteer to take care of the merges for the next few releases. I'll clearly track down the time spent doing this, and we can have a clear image on what that would mean. 
>> If it doesn't work we can always use the other approach (it would work though :) )
> 
> Of course it will *work*.  It will just waste a lot of time and have us delay releases.  Which I don't want to do.
I kindly disagree. Yesterday's conflict resolution stage took me less than 20 minutes. The merge on the server was about 40 mins, but during this time you can read email or do whatever stuff you want to(and you'll do it anyway just to make sure people didn't forgot to port stuff over).
Why not just prototyping it and see? It's not something we need to do if it doesn't work. 
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev