It's all about the answers!

Ask a question

how to accept changesets on stream automatically (Flow target)


Karthik Krishnan (859498146) | asked May 12 '14, 9:23 a.m.
edited May 13 '14, 8:22 a.m. by Ralph Schoon (59.7k23643)
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

Accepted answer


permanent link
Karthik Krishnan (859498146) | answered May 14 '14, 12:37 p.m.
edited May 17 '14, 2:23 a.m.
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

2 other answers



permanent link
sam detweiler (12.5k6184201) | answered May 12 '14, 10:03 a.m.
seems like the -s (source) or -t (target) parameters  should work on scm (or lscm) accept.

Comments
Karthik Krishnan commented May 12 '14, 12:44 p.m.

 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
Karthik Krishnan (859498146) | answered May 13 '14, 8:14 a.m.
Perhaps "Accept" is not what I need.

I need to use 'lscm deliver'





Comments
1
Ralph Schoon commented May 13 '14, 8:27 a.m. | edited May 13 '14, 8:56 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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


Karthik Krishnan commented May 13 '14, 9:01 a.m.

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 " 
 


Karthik Krishnan commented May 13 '14, 9:23 a.m.

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


Karthik Krishnan commented May 13 '14, 11:08 a.m.

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?


sam detweiler commented May 13 '14, 11:27 a.m.

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). 


1
Ralph Schoon commented May 13 '14, 11:44 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.


Karthik Krishnan commented May 13 '14, 12:04 p.m.

@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


Ralph Schoon commented May 13 '14, 1:15 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.


sam detweiler commented May 13 '14, 1:26 p.m.

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 to post your answer.