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).

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.

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 :) )

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

I would have expected people to work on trunk and eventually backport fixes to previous branch?

That's how I have been working the latest weeks; actually the Lucene Directory was a bit different between the two branches because of differences in core API; but after this merge they turn out to be identical, so this approach caused some confusion to me - I've been maintaining two versions but it wasn't necessary. Weird result!: different patch history on both branches, but resulting now in the same code, if you ignore some blank lines; going to fix now the blank lines issues so that they are totally equal (besides pom version).

Cheers, Sanne 2010/7/2 Mircea Markus <mircea.markus(a)jboss.com&gt;: > > On 1 Jul 2010, at 19:17, Manik Surtani wrote: > >> >> 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 > no. "svn merge" keeps track of individual commits, even over a merge. This file was added by you on 4.1.x, here is what svn log shows after the merge in trunk: > > [mmarkus:~/code/ispn ]$ svn log trunk/cachestore/jdbc/src/main/java/org/infinispan/loaders/jdbc/AbstractNonDelegatingJdbcCacheStoreConfig.java > ------------------------------------------------------------------------ > r1951 | mircea.markus | 2010-07-01 18:00:41 +0300 (Thu, 01 Jul 2010) | 1 line > > merge from 4.1.x (r1875 to r1949) > ------------------------------------------------------------------------ > r1949 | manik.surtani(a)jboss.com | 2010-07-01 14:52:46 +0300 (Thu, 01 Jul 2010) | 1 line > > [ISPN-368] (Remove code duplication in certain JDBC configuration classes) >> >> -- >> 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 > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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.

-- 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

So, although I'd like each to choose the way they wanted to work, problems like the one I just mentioned require some kind of agreement on dealing with a particular branch in order to avoid these issues.