Hi guys,

This feature is now officially released in Bamboo 2.0!

For more information about the release, check out our release notes.

You can download the latest release here today!

Regards,
Edwin

Great to hear! We'll give it a spin once published.

Folks,

This will be available for the next beta (beta7), which will come out next Tuesday. It's implemented as an optional advanced setting for SVN.

Cheers,

Mark C

An additional use case for me in support of this feature. We require meaningful comments (e.g. brief description of the change made to the file, JIRA issue key related, etc.) to be attached to each file checked in to our SVN repository. Therefore, if I'm checking in 6 files and each needs a different comment, often times the polling interval will pass before I'm done checking in each file. This will result in a broken build if all 6 changes are necessary for the tests to pass.

AntHill has this feature

Guys,

We're not rejecting the feature by any means and I believe this and BAM-1248 can co-exist quite happily as options. Which one you go for really depends on your setup.

If you have a project with a 100 commits a day and 40 minute builds (like Andrew has) BAM-926 is probably more practical. If you have 20 commits a day (like Matt has in his Confluence builds), you can probably afford to be stricter with triggering builds per commit (BAM-1248).

On a general note, I guess this is why we have our issues public. This issue already has quite a few votes and many watchers, so it's fairly clear that your use case is far from uncommon. When we address the atomic commit issue, we're quite likely to address this issue as well.

Cheers,

Mark C

PS As a side note, Matt's a Confluence developer, so he's just putting his 2 cents on this topic, rather than making a call on behalf of the Bamboo team. In JIRA land, he's still only got one vote

Guys, what you are telling is all nice, but face the reality - if you reject this feature as in 'you should do it this (right) way', the one to lose would be Atlassian, by angering users with the lack of such trivial and expected feature.

That sounds much the same as 'distributed transactional systems must never fail because you have a fully-functional XA transaction manager'. Guess what, they fail, and to the extent that standard heuristic exceptions have been introduced to denote cases when it gives up and requires manual intervention/resolution. Don't fix the world, this attempt would fail.

This could be useful even in Subversion. I am often encountering this problem: I make an atomic Subversion commit which contains interdependent changes between multiple Bamboo build plans. Bamboo then does not always build the plans in the right order.

I don't understand why this is required. I want the opposite (BAM-1248), where every commit is guaranteed to generate a single build.

Andrew, it sounds like you want to make a breaking commit to the repository, but not have the build fail. If the team doesn't want to fail the build, they should ensure the repository is never in an inconsistent state. If the repository is ever in a broken state, it's the responsibility of the build system to report that.

For the former real-life scenario (involving multiple components), you can version your components using a dependency management system like Maven or Ivy. Don't change the version of component A that component B depends on until the changes to component A have been committed, tested and released as a new version. This is how we manage our internal dependencies at Atlassian, for example.

For the latter real-life scenario (involving geographically-separate interdependent commits), how can the developers be sure that their changes will even function together without consolidating their work first? The only sane way to commit this kind of work is to integrate it all on a single workstation and test it before committing. Anything else is more likely to fail the build simply due to incompatibilities, even if Bamboo did wait to pick up both commits.

If the above didn't convince you, here's another real-life scenario. Developers are spread across continents. The next build should contain changes from both of them. They agree (over the mailing list / phone) they are ready to go with their changes which are complimentary to each other. There's no technical way to commit those in one changeset, isn't it? So, they want to commit at the same time, and have the server pick their changes altogether, not randomly jumping in.

The transactional nature of changesets in SVN was designed with different goals in mind, and it does it well. We're discussing a higher-level feature. Consider the difference between an ACID transaction in itself and a BPM solution with compensating transactions.