Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

how to accept changesets on stream automatically (Flow target)

I have 2 streams on different repositories and both the streams are set as flow targets 

For argument sake I will name them as following

R1, S1 (Repository 1 & Stream 1)
R2, S2 (Repository 2 & Stream 2)
 
S1 & S2 are set as flow targets.

When there are new changesets in S1, the same is shown as incoming at stream S2. 

I am wondering if it i possible to accept changesets on S2 automatically using SCM tools

Of course there could be merge conflicts but that's next step

thanks

0 votes


Accepted answer

Permanent link
OK. This is what I have done

- Use LSCM Deliver instead of accept as accept works only on target workspace and not stream.
- adjust the Preconditions in Operations behavior to accept change set without work items (only for Replicator)
- Use a continuous integration build on both the REPO to transfer change sets between 2 repositories.

Of course this only works when there are no conflicts 

Thanks @Ralph, @Sam and @gmclemm for your suggestions

Edit:: The Preconditions in Operations behavior somewhat confused me. 

On R2 delivering between 2 streams I had to adjust the "Deliver (client)" preconditions. 
Ralph Schoon selected this answer as the correct answer

0 votes


2 other answers

Permanent link
seems like the -s (source) or -t (target) parameters  should work on scm (or lscm) accept.

1 vote

Comments

 Thanks Sam


I tried this 

lscm accept -s "S1@https://R1:9443/ccm/"  -t "S2@https://R2:9443/ccm/" -v

and got 

Problem running 'accept':
Unmatched workspace "S2"

Like I mentioned in my question S1 & S2 are streams


Permanent link
Perhaps "Accept" is not what I need.

I need to use 'lscm deliver'




0 votes

Comments

Accept is the opposite direction. You should be able to tell, which direction you want. I did this in the Eclipse client yesterday. Maybe you have a typo in the stream names? (The flow target does not play a role here I guess, since it is not a loaded repo workspace. See https://jazz.net/help-dev/clm/topic/com.ibm.team.scm.doc/topics/accept.html. )

-s, --source <arg> Selects the source workspace or stream from which the changes will flow. To specify the workspace or stream, use its name[@repo], alias, or UUID[@repo].

-t, --target <arg> Selects the target workspace into which the changes will flow. To specify the workspace, use its name[@repo], alias, or UUID[@repo].

If you get it right, I would expect it to work

1 vote

Correct but "lscm Accept" was always throwing me  error "Unmatched workspace.."


Now that "lscm deliver" works, how can I associate a work item to changeset(s) 

I am delivering changesets from Stream 1 (S1) in Repository 1 (R1) to Stream 2 (S2) in Repository 2 (R2) (Distributed SCM setup)

We have the process description that each change set must be associated with a work item

During "lscm deliver" this causes a problem as the changeset from R1 needs to be linked to a workitem in R2

There can be one more changesets at the point of "lscm deliver" 

How can I link these changesets to a workitem in R2?

My approach is to have a continuous build on R1 & R2 to perform the "lscm deliver " 
 

Looks like "deliver" won't work for me as I need to associate a work item on R2 and then accept. 


Not sure if I can associate  a workitem from R2 and then Deliver to S2

looking carefully it looks like 'lscm accept' works when the target is a workspace.


not sure if this is a good idea in Distributed SCM environment..any thoughts how I can accept the incoming changeset on Stream level?

I don't think you can associate a changeset on system 1 with a workitem on system 2. 


stream to stream delivers or accepts EVERYTHING different between them.
if you want to be selective you have to use a workspace, and change the flow target
accept from stream 1, deliver to stream 2. 

the (current) flow target can be on another system (DSCM). 

There is a stream to stream deliver at least, where the streams can be on different CML instances (DSCM). this works in the client. A Stream is not that different from a workspace. If you need to resolve conflicts you need a repository workspace.

I would suggest to create a work item if this is broken for you. Work Item references are replicated, but the work item will only know about the original change set in its repository. You can link remote change sets to work items using a Change Request work item. this is a different link type.

1 vote

@Sam

- I simply want to deliver all from Stream 1 to Stream 2 (conflicts aside) & vice-versa
-  
- Just saw that RTC 5.0 SCM tools has the mechanism to associate workitems from different repo

- Yes I understand that for conflicts we need a workspace
- My idea is a to have a workitem on both the repo and to link changesets accordingly only to this repo 
- I tried the "lscm add workitem" but does not take work items from other repositroy

This is what i did
lscm add workitem -u replicator -P replicator -r https://R2:9443/ccm/ 1174@https://R1:9443/ccm/  10

where 1174 is the changeset UUid @ R1 and workitem 10 is at R2
we are on RTc 4.0.5

You can meet Tim Feeney and me at Innovate talking about these considerations on Wednesday.

You will see the work item on both sides but the work item will only refer back to the local change set. If you make the CCM server friends, you will however be able to see the work item from thew change set.

We will try to bring over what we found into the deployment Wiki.

Sadly no chance for Innovate for me this year. Will miss meeting u again. 

showing 5 of 9 show 4 more comments

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,938

Question asked: May 12 '14, 9:23 a.m.

Question was seen: 4,668 times

Last updated: May 17 '14, 2:23 a.m.

Confirmation Cancel Confirm