How to Detect Conflict/Overwritten Files in Hudson or Cruise Control

Question

Hi,

Lets say two front end developers are working on the same file just for changing a css propery without knowing each other.They both work in their own branch in the source control.

First developer's css changed file deployed to the test system, and it is still in test phase.

Before the first developer's change is approved and deployed to production, second developer's css changed file deployed to the test system and overwrote the first developer's version.

Is there any feature that tracks each file's status< on prod, test pass,still in test, test fail, ready for prod etc. > on the test system in Hudson or Cruise Control.

And also is there any feature in Hudson or Cruise Control that warns or protects this kind of overwrite/merge/conflict cases for this small css cahnge case.

Best Regards

Answer 1

If they work on their own branches it's up to the integration of those two branches to detect such kind of "overwriting"...and not the task of an continious integration. It would be a good idea to have an integration branch which integrates the first branch do some testing (deploying on test system etc.) and after that the second branch will be integrated to the integration branch. During the merge of the changes of the second it would strike on someones eye that there is a conflict there.

Answer 2

This sounds like a screwed set up. You are deploying two different branches to the same test environment. You should make sure, that the tests for the first branch runs successful, before you overwrite the deployment from the second branch. I would do that manually or better, I would create an Integration branch, (usually trunk or the current production release branch) to integrate and use this branch only to run the tests.

Actually, you have a process problem here. The issue that you describe sounds like a bug fixing issue. Standard procedure should be, that someone claims the bug before fixing it. The first one claiming it, has the honor to fix it. This way you don't run into the issue of two people fixing the same bug. If the bug was not reported before, report it first and than claim it, before fixing it. Sounds like overhead? Yes, but this is called project management and helps you to save time (and therefore money) in the long run. If this type of formal communication is to much for you, you can have a chat room for your developers to post to, when they found something that needs fixing. But chat rooms only work for small teams and when all teams work in the same time zone.