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

On 1 Jul 2010, at 17: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? Also you end up with big blob commits which means you lose all context of a commit (who did what, when, and why) and this completely negates all of the benefits of atomic commits, commit messages, and the like. E.g. it's pretty tough to make sense of this, right? :) http://fisheye.jboss.org/changelog/Infinispan/trunk?cs=1951

-- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev