If "others have modified components since you checked out the system", what would you do?

Question

In Software Engineering by Pressman:

The steps in continuous integration are:

1. Check out the mainline system from the version management system into the developer's private workspace.
2. Build the system and run automated tests to ensure that the built system passes all tests. If not, the build is broken and you should inform whoever checked in the last baseline system. They are responsible for repairing the problem.
3. Make the changes to the system components.
4. Build the system in the private workspace and rerun system tests. If the tests fail, continue editing.
5. Once the system has passed its tests, check it into the build system but do not commit it as a new system baseline.
6. Build the system on the build server and run the tests. You need to do this in case others have modified components since you checked out the system. If this is the case, check out the components that have failed and edit these so that tests pass on your private workspace.
7. If the system passes its tests on the build system, then commit the changes you have made as a new baseline in the system mainline.

I was wondering what does this in 6 means:

If this is the case, check out the components that have failed and edit these so that tests pass on your private workspace.

?

What does "these" in "edit these" refer to? The components that was modified by others since I last last check out? Or the components that was changed by me after my last last check out?

If "others have modified components since you checked out the system", what would you do?

Note the book used CVS as version control tool. Will it be different if using Git?

Thanks.

Answer 1

What does "these" in "edit these" refer to? The components that was modified by others since I last last check out? Or the components that was changed by me after my last last check out?

Honestly it's both. Obviously if you can resolve the conflict by sticking to editing the components you were already making changes to it's better. If you can't you need to dig into why and see if you can figure out why the changes in the other components make what you're trying to do impossible. Those other components were likely changed for a reason so if you 'fix' them you're on the hook for that too. It might be some massive architectural restructuring. It might be a typo. Merge conflicts come in many sizes. Sometimes you just need to talk to whoever broke your stuff.

Keeping problems like this small is why you should commit and merge often.

Answer 2

Any time you want to put your changes into the base line, someone might have made different changes.

You want your code to merge without merge conflicts. Actually what you want is that the baseline, combined with your changes, exactly matches your changes because this is what you have tested. The typical sequence:

1. You branch from the baseline.
2. You spend say a week to create a new version with your changes.
3. You merge the baseline into your work, solve merge conflicts, and make all changes needed to make it work again. Say that takes a day.
4. If there were any changes then go back to Step 3.
5. Create a pull request. Fix all changes due to comments and have them reviewed, and merge your changes if ther is no merge conflict.