Hi all, the master branch is not compiling since the last commit "b6de38a", but even before that it's not very clean: I'm seeing many branch merges, history is an mess.

I'm going to recommend again to use Emmanuel's nice build script https://gist.github.com/789588 which verifies you're actually testing the commit and not depending on other state, and to really avoid using the web interface only to do reviews and handle pull requests. I know that's adding a bit of a burden to the reviewer's time, but that's why the original committer should polish his patch in a logical sequence and add enough commit comments to ease the reviewer's work as much as possible; otherwise it seems that more often the reviewer does more work than the original developer, who is not even taking responsibility for his code as someone else will check it. I'm not angry :) just worried the discipline is getting a bit too low for the very demanding standards we aim for and calling for some more attention.

Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 30 sept. 2011, at 16:46, Mircea Markus wrote: > Now there's a reason why merge was used there and not rebase. If you add a new file in a topic branch and modify it in several commits on the same topic branch, then during rebase git sees all these individual commits on the same files as conflicts, which makes rebase a real PTA. Optimistic locking impl had 52 commits, most of them touching same classes. There may be something else at play here. I'm almost certain that if you add a new file and subsequently change it in a topic branch and afterwards rebase to another branch it works without conflict.

> +1. My only concern is that during the 10 mins in which I run the tests, my laptop cannot be used for development. Hopefully I'll get a new, more performant one next spring :) Ask Steve J an ssh access to his machine and run the build from there. That might speed things up :)

+1. My only concern is that during the 10 mins in which I run the tests, my laptop cannot be used for development. Hopefully I'll get a new, more performant one next spring :) Ask Steve J an ssh access to his machine and run the build from there. That might speed things up :) Jokes aside, this is what I do with some of the QE servers. That can work. How do you sync with the QE guys though? _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

A decent operating system can do some work in background while not killing the user capability to do something :)

> Jokes aside, this is what I do with some of the QE servers. That can work. How do you sync with the QE guys though?

I don't. I just check for other java processes running beforehand. So don't follow my lead, I need to not do that myself. :)

On 30 September 2011 15:50, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > On 30 sept. 2011, at 16:46, Mircea Markus wrote: > > Now there's a reason why merge was used there and not rebase. If you add a > new file in a topic branch and modify it in several commits on the same > topic branch, then during rebase git sees all these individual commits on > the same files as conflicts, which makes rebase a real PTA. Optimistic > locking impl had 52 commits, most of them touching same classes. > > There may be something else at play here. I'm almost certain that if you add > a new file and subsequently change it in a topic branch and afterwards > rebase to another branch it works without conflict.

On 30 September 2011 15:50, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > On 30 sept. 2011, at 16:46, Mircea Markus wrote: > > Now there's a reason why merge was used there and not rebase. If you add a > new file in a topic branch and modify it in several commits on the same > topic branch, then during rebase git sees all these individual commits on > the same files as conflicts, which makes rebase a real PTA. Optimistic > locking impl had 52 commits, most of them touching same classes. > > There may be something else at play here. I'm almost certain that if you add > a new file and subsequently change it in a topic branch and afterwards > rebase to another branch it works without conflict. There are ways to avoid most conflicts, it was quite amazing to realize yesterday that after changing almost all file position in Search *twice* in a week, pending complex pull requests (from contributors!) and work in progress we had in other branches could just be rebased without any conflict: all the changes we made didn't make it any harder, so I guess it can help to plan the order of changes, that's also why I'm reworking the commit sequence regularly if I'm not integrating soon. In the meantime I found more problems :) it's not only the last commit breaking the compilation, even before that somebody has been cleaning up the TestCacheManagerFactory without checking what was being used by non-core modules. This likely happened because tests fail all the time so it's hard to run a full build and check if any change is safe. Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev