Breaking the build for a couple days

Question

I recently sent an email to my colleagues explaining that I need to make some changes in our shared ClearCase view which will mean that our project will be in a non-compilable state for a day or two.

One guy is complaining about this. What can I do to prevent his complaining?

Answer 1

Make your changes in a separate branch, and take responsibility for merging your changes when you're done.

I can certainly understand why your colleague might complain about this - you're essentially preventing him/her from doing the work that they had otherwise planned to do.

Answer 2

Either

• Explain to him why you have to do it and he will understand if there is no better solution

or

• Do the better solution

---

Edit:

I don't know why I got a down vote for this. Basically, I'm saying you should not try to "prevent him from complaining". Either he doesn't appreciate why what you are doing is the best solution, or what you're doing isn't the best solution. Just walk over and chat to the guy about it and discuss the problem until you both agree with each other.

One of you is right and one of you is wrong, I'm not saying which, I don't have enough information.

Answer 3

If you're using SVN this should be a simple Branch. Else you might want to consider a copy/past operation and merge yourself at the end.

Personally I think telling others that stuff their working on will be in a non compilable state for a couple of days is kinda outrageous. You're essentially telling your peers two things.

1. Your changes are much more important than theirs
2. You won't be able to work for a couple of days.

Answer 4

You can prevent his complaining by not breaking the build!

The build isn't just someone nightly process that happens over in the corner somewhere that nobody cares about - it happens on every developers machine every time they want to debug or test anything!

If the build is broken on the build machine its broken on every developers machine - To developers the build should be sacred as a broken build means other people aren't able to do their work.

In terms of what you can do to prevent your changes from breaking the build, it depends a lot on what it is that you are changing, however some generic suggestions are:

• Make your change on a separate branch and merge it in once its finished
• Avoid making large changes, and instead split your change into many smaller non-breaking commits.

Answer 5

The ClearCase way to handle this kind of situation (which can happen when doing a long and complicated merge for instance) is:

• first put a label to identify the situation before any changes
• start the modifications

• if the process takes too long and the other users are affected (either because their dynamic views reflect * immediately* the new versions, or because they need to update their snapshot view, or because you are using the same view, which is possible with dynamic view), then:

  • at least stop sharing the same view, and create your own: if this is a snapshot view, you can use the same config spec. Don't checkin until it compiles again
  • ideally, create it with your own branch, starting from the label: that way you can make intermediate checkins, and then merge it back at the end.

A config spec for using your own branch, starting from the label you would have put before making any dangerous changes would look like:

    element * .../MyBranch LATEST
    element * MY_LABEL -mkbranch myBranch
    element /main/LATEST