I have always assumed that (1) and (2) are true. My "solution" is to stay on a single private branch based on the latest NetBeans release (currently 11.3), rather than the master branch, and pile up a few different patches before I start making Pull Requests. That way I normally only have to compile modules that actually have changed source files in them (by invoking "ant").
Only once I'm ready to start making a few pull requests in batch do I switch to the NetBeans master branch, pull the latest changes, create a PR branch, and apply my patch(es) (via "git cherry-pick"). I don't even rebuild on my own machine at that point--the automatic Travis build that starts when you create a PR will work as a sanity check of this "rebase". Other useful commands are "git rebase upstream/master" (assuming "upstream" is set to https://github.com/apache/netbeans ) and "git rebase -i HEAD~10" (or such) for squashing or reordering commits for PR creation purposes. Are you on Windows, Linux, or MacOS? -- Eirik -----Original Message----- From: Korney Czukowski <czukow...@seznam.cz> Sent: Thursday, February 27, 2020 2:59 AM To: dev@netbeans.apache.org Subject: NetBeans Development Setup Hi, I've read an older thread with the same name and while there's a lot of useful information, I could really use some clarification on working with branches: 1. I assume whenever I decide to pull changes from upstream, a full ant build is necessary, and there's no way around it, correct? 2. When I work on my branch to fix an issue in one of the NetBeans modules and then switch to another branch to work on a different module, is full build (or cluster build, if applicable) necessary again? It would appear so to me, because I've seen some weird exceptions occurring when running a module after switching branches. But the full build takes a huge amount of time and is often interrupted eg. when it can't download something from gitbox.apache.org, etc. So I'm trying to find a way to avoid it whenever possible, because otherwise the time that could be spent on debugging and fixing issues is actually being spent on waiting for build, without being able to do anything else. Thanks.
