1

I have a problem here with the branch per task strategy in clearcase.
We are using snapshot views. We have various task branches and an integration branch.
So, we merge the branches to integration for testing.

Now, suppose I am working on a file on BR1 which is merged to integration branch and this file refers to another file which is not merged to integration branch but BR2 for the second file is merged to integration branch.

So, second file is pointing to the BR2 edition of the file whereas I didn't want those changes but since I am taking all other code from integration branch, its taking that version.

This is my config spec:

element * CHECKEDOUT
element * .../BR1/LATEST
element * .../integration/LATEST -mkbranch BR1
element * /main/LATEST -mkbranch integration
element * /main/0 -mkbranch integration

Is there any way to resolve? One way I could think of is putting a label so ,change the config spec to pick from that label and not from latest of integration branch but that would need changing the labels as the work gets progressed in the task branches.is there any other way we could do this?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
user2636464
  • 685
  • 7
  • 17

1 Answers1

1

The integration branch is there to integrate, so if you are doing work from that branch, I would really advise you to take all those files.

If the issue is only for one file, you simply can try a "cherry-pick" approach, and checkout that file in your current BR1 branch, replacing its content with any other version you want (with a cleartool get, for instance, as detailed in "Clearcase command to export an element").

Considering your config spec, I would recommend:

  • putting a label 'L_BR1' just after merging BR1 to Integration,
  • select that label over the LATEST of Integration (which contains version merged from BR2)

That would mean a config spec like:

element * CHECKEDOUT
element * .../BR1/LATEST
element * .../integration/L_BR1 -mkbranch BR1    <=== add this select rule
element * .../integration/LATEST -mkbranch BR1
element * /main/LATEST -mkbranch integration
element * /main/0 -mkbranch integration

Caveat: be ware, though, that it wouldn't work well on cross-integrations (when you merge BR1 to Integration, then BR2, then again BR1)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Its not an issue with one file. its hundreds of files on BR1 which don't want changes from BR2 which have been merged to integration branch? .Issue is for working on particular task, I would not really want to take changes from other branches which have been merged to the integration branch. I hope you got my concern? – user2636464 Oct 29 '13 at 09:50
  • @user2636464 then why are you looking at files on the integration branch, since they are, by definition, integrated with other issues, since it is an *integration* branch? – VonC Oct 29 '13 at 09:52
  • @user2636464 you can edit your question with your config spec. – VonC Oct 29 '13 at 12:40
  • @user2636464 your label approach has merit then. I have edited my answer to illustrate it. – VonC Oct 29 '13 at 19:26
  • Caveat: be ware, though, that it wouldn't work well on cross-integrations (when you merge BR1 to Integration, then BR2, then again BR1)" can the issue be not resolved by moving the label just before we are going to do a new merge for BR1 to integration? – user2636464 Oct 30 '13 at 06:14
  • @user2636464 yes, but that will include versions made by BR2 merges. If you still don't want those... you would get them anyway. – VonC Oct 30 '13 at 06:19
  • I think it won't because I would label on BR1 branch just before I am merging to the integration branch. am i right? – user2636464 Oct 30 '13 at 07:17
  • @user2636464 no because the label I mention is one put on Integration branch, not on BR1 branch: you view is made to view the LATEST versions on BR1. – VonC Oct 30 '13 at 07:26