Community
Participate
Working Groups
Switching branches/rebasing/etc. should not wait for Maven or PDE to finish building. Once the rebase happens everything would need to be rebuilt anyway. This means that unless I take special action to manually abort the build, I have to wait for everything to build *twice,* or more if I need to do a series of git operations.
So you want EGit to abort the build when checking out another branch while the build is running ?
Switching branches while building can cause trouble for the build and fail it in unpredictable way. So -1 from me. So either we ask "do you want to abort the build" or we wait.
I didn't mean to run checkout during build concurrently. If we implement this and the user triggers checkout while a build is running we either explicitly abort the build and then execute checkout or we first show a dialog to get the user's consent for aborting the build or we first wait for the build to complete. I think we should implement both options and provide a preference Team > Git > Confirmations and Warnings > Abort concurrent build if git operation modifies working tree with possible values yes/no/ask, default should be ask
I think aborting the build would make sense. If the build relies on files that the user asked EGit to change, I can't understand in what scenario the user would want EGit to wait for the build to finish. If Eclipse is building and you want that build to finish, presumably it's so that you can either run something or verify that it builds successfully. In either case you wouldn't initiate a Git operation during the build. Note that other things (launches) may be waiting for the build to complete, so I don't think EGit's waiting makes much sense unless it also waits for those things to happen, otherwise it may disrupt them instead of disrupting the build. But I think in most cases where the user initiates a git operation during a build, it's because they didn't want that build to happen at all, e.g. they are in the middle of a rebase and Eclipse decided to build. I'm very surprised this hasn't come up before, as I find it quite an annoyance.
It also seems to me that staging files should never wait for a build to complete, since it has no impact on the build.
I have been wondering for a long time why our IndexDiffCacheEntry recalculation waits for the workspace lock at all. Indeed it leads at least in the staging view to an annoying and completely unnecessary delay in the UI update when builds are running. (The staging view updates its UI in response to changes in the index diff calculation. If that gets blocked by a build, the UI update will occur only once the build is over.) Note that changing this in IndexDiffCacheEntry may negatively impact our test suite; we already have a number of tests that became unstable since the "parallel pull" changed the scheduling rule there. So the tests may need to be changed, too. See bug 541124.
Another example: if I want to cherry-pick a bunch of commits onto my branch, after each cherry-pick, Eclipse starts building my workspace and I have to wait for the build to finish before I can cherry-pick the next commit, but I don't even want anything to build until I have finished cherry-picking everything, so I (if I remember) turn off 'build automatically.'
