If you are looking for Jitsi Meet, the WebRTC compatible video conferencing product click here.

Committing Code

Committing code to version control (SVN or GIT) is a delicate business. Franz Garsombke once said in a JDJ article:

Murphy’s Law states that a developer would check code in on Friday and break the build without anyone knowing it. Many weekends were lost due to bad builds.

It is amazing how easy it is for someone to break the build. You could forget to ‘svn add’ a file, a library, not commit all of your changes, or even (but that one doesn’t happen in our project, right? :) ) commit without really trying to build and run your code locally. Committing build-breaking code is something that could be very annoying. It will keep others from updating their SVN sandboxes and commit code. Even worse - it could break their own builds because they’ve updated from SVN without knowing that there was a problem. In other words - it causes everyone to lose time.

It is still amazingly easy to make sure that the build won’t break or to quickly fix it if that happens. Here are a few tips on how to do that (tried to keep it short so that we all remember it by heart):

Before Committing Code

  • Run a ‘svn update’ to merge your code with the latest repository changes.
  • Build the project locally.
  • Run the cc-buildloop target and verify that all SLICKs and unit tests pass successfully.

If all of the above have went on smoothly, you could go on and bravely commit!

Stay focused, it’s not over yet ;)

After Committing Code

  • Wait for the Cruise Control mail.

Our installation of CruiseControl builds the project every 10 minutes and sends a confirmation mail indicating build success or failure. If you believe that you don’t have the time to wait for it then please DO NOT COMMIT!

  • If the build is a Success.

Congratulations - you may now rest and be please with your latest commit! Note that if you have added new libraries, you should advertise it on the community forum. This will allow the package and IDE maintainers to update the necessary library classpath.

  • If the mail indicates a build failure.

Examine the problems indicated by the mail and try to resolve them. A good way of reproducing the problem would be ‘svn checkout’-ing the code to a location other than your sandbox and running the cc-buildloop target on it. That’s what CruiseControl does and that’s what others generally do.

If you believe that the solution is not a matter of a few minutes, you may want to consider rolling back some or all of your changes so that the build gets fixed and others are not prevented from working on it.

  • If you can’t find/fix the problem and rolling back doesn’t seem to help

Try to discuss the problem on the community forum.

  • If even after all of your efforts, the build goes on failing.

Chill out! Stuff like this happens. As long as you treat the issue responsibly, no one is going to accuse you of anything, so go get some sleep and get back to that in the morning ;)

Author: Emil Ivov