Comments on: Don’t Break the Build: A Developer’s Guide to Care-Free Commits

By: george

george — Mon, 16 Nov 2009 06:27:55 +0000

Nice hat!

Don’t be so hard on yourself. It happens to us all

By: Pavel Sher

Pavel Sher — Sat, 07 Nov 2009 12:03:11 +0000

Speaking about better continuous integration systems: take a look at TeamCity. It offers pre-tested commit feature to solve the 5 o’clock problem and it does not require decentralized SCM for this: http://www.jetbrains.com/teamcity/delayed_commit.html

Moreover while the build with non-committed changes is running you can modify the same files.

By: SteveC

SteveC — Sun, 11 Oct 2009 00:28:05 +0000

How do you handle the situation in which the code you commit gets compiled on 50 distributions of linux with god knows what compilers?

Still thing breaking the build is a shooting offense?

By: David Shepherd

David Shepherd — Thu, 08 Oct 2009 22:17:53 +0000

I would agree with Ketan and Neil that having uncommitted changes for more than one bug or feature is best avoided. Unfortunately a lot of developers find themselves forced into this situation on a regular basis, which is why tools like Eclipse and ClearCase UCM provide manual facilities for tracking change sets. One of the main advantages of Tasktop’s change sets is that Tasktop automatically creates change sets, whereas developers were previously forced to construct them manually.

For those that are lucky enough to have a development process and tools that make it easy to work on one thing at once, you will still get the benefit of the automatic commit comments, automatically generated change sets, etc.. We’ll have more on these further advantages of Tasktop’s change set management in an upcoming post…

By: Neil Bartlett

Neil Bartlett — Thu, 08 Oct 2009 11:22:25 +0000

I’m with the other commenters who feel that working on multiple uncommitted changes, and making partial commits, is wrong and dangerous, no matter how much support Mylyn gives you for tracking changes with respect to tasks.

The problem is that my local build will always see all the changes I have made, irrespective of task, and therefore if I only check in part of those changes there is a substantial risk of breaking the build even when my local build is green.

A better solution is a version control system like Git, that allows quick switching between local branches and ease of merging across those branches.

Oh and another thing, in your bug list snapshot: “British spelling used on homepage” is not a bug, it’s a feature!

By: James

James — Thu, 08 Oct 2009 09:17:23 +0000

Great post, and good motivation for people to get on board with Tasktop.

I presume there’s one case that Tasktop can’t help with. That would be where I’m working on two tasks but both will involve a common class. I’m guessing that by committing from Task1, changes I made to the class while in the context of Task2 will get committed too? This is the case where the developer needs to use the working memory

James

By: Tamir

Tamir — Thu, 08 Oct 2009 06:31:00 +0000

It sounds interesting. If you plan to support ClearCase soon, you’d better know that it’s much more necessary in Base ClearCase rather than UCM ClearCase. In UCM, you can manage your tasks (activities) quite tightly, and if you integrate your environment with ClearQuest – even more.

By: Ketan Padegaonkar

Ketan Padegaonkar — Thu, 08 Oct 2009 03:41:55 +0000

Developers working on major changes on 5 different things *seems* to be wrong. Working on small chunks that enable developers to check in early, check in often is often a good idea

Also DSCM that keeps track of local branches helps heaps in such cases — it is not always true that 5 features require 5 different sets of files; there would always be something that is common. Git for example allows for me to check in parts of a file into a commit.

Mylyn is a really great way to solve the multitasking issue, and I love this aspect of mylyn when it helps ease switching context — but working on multiple features at the same time and not checking in into source control seems to be a very wrong thing to do.

By: David Shepherd

David Shepherd — Wed, 07 Oct 2009 21:26:50 +0000

Jilles,
You raise some great points. I totally agree that better version control and continuous integration practices are the right way address the underlying problem of broken builds. Although builds are only one developer’s problem in the scenario you describe, grouping modified files by task still helps developers avoid having their commits rejected from untested. This approach also helps developers know which files to revert or update from tested on a per-task basis when working on several things at once. Keep in mind that the tooling makes the task to file mapping explicit but doesn’t actually enforce work flow. Another way Tasktop and Mylyn can help nip problems in the bud before committing is by quickly running only the JUnit tests that test the code changed as part of a given development task.

Good luck convincing your colleagues to join this century!

By: Jilles van Gurp

Jilles van Gurp — Wed, 07 Oct 2009 17:12:17 +0000

The real, underlying problem that needs addressing here is better addressed by continuous integration and decentralized version management systems.

The problem is inherent to any kind of centralized repository where people can just dump any change. Fact: people make mistakes. Without control, that leads to broken builds. Bureaucracy (do this or that or you get to where the stupid hat) or tools that automate parts of the bureaucracy are not a real solution, they just address the symptoms. Worse Bureaucracy is a workaround. It’s inefficient. It’s annoying, it takes time. You constantly have to ‘educate’ people about it. Lazyness is a sign of intelligence, something to value. Tools that allow intelligent people to relax and be lazy are good.

With decentralized version management, committing changes from push to pull. So if you set up some continuous integration server that pulls changes from a untested repository (or some email server), that tests the changes and pushes them to a tested repository, this problem is solved. You commit/email your changes to untested. Nobody but the integration server pulls from there. Only changes that pass compilation + unit tests get pushed to tested. Failing changes are rejected and automatically removed from untested. Everybody pulls changes from tested that have passed the test suite and are guaranteed to compile. Always. You break untested, it’s your problem: as it should be.

You can layer this of course and insert more repositories with more and more checks and balances between them. Great for scaling up development to multiple teams.

Now if I’d only be able to convince my colleagues to ditch their 20th century version control technology and move their ass into this century …