Copying source code from RTC 4.0 to RTC 4.0.5
Hello All, We are in the process of upgrading our clm version from 4.0 to 4.0.5. We have 2 environments(Production & Integration).
We have first successfully upgraded our integration environment from RTC 4.0 to RTC 4.0.5.
The version upgradation was successful. Now we are testing the features of 4.0.5 and we would like to copy some source code data from the production environment which is still in RTC 4.0 version.
However when I try to create some streams and add components. I get some errors. Steps to re-produce : 1. Open any project in RTC 4.0.5 version (In this scenario, it's integration system) 2.Create a stream 3. Add a component which is from another repository(production system, RTC 4.0 version) 4.Save the stream
error :
So is it expected that version 4.0 source code cannot be copied to 4.0.5 ?
Please advice,
Thank you Vishnu M |
One answer
https://jazz.net/library/article/535#Appendix
Those versions are not compatible with each other for the distributed source control feature. You'll have to upgrade the older server before it will work again. Comments Hello Tim,
By performing a version upgrade from 4.0 to 4.0.5, will there be any effects on the source code, build definitions/configurations ?
that is the reason we are trying to test in the 1st place with production data.
Thanks! Tim,
I checked the url you provided. https://jazz.net/library/article/535#Appendix
However here it is mentioned RTC 4.0.5 is not compatible with RTC 4.0.4 or before.
But I am trying to copy RTC 4.0 data(production) to RTC 4.0.5(integration).
Hence it's from RTC 4.0 to RTC 4.0.5. not the other way around as mentioned here
Thanks Vishnu M I do not think it will affect your source code or anything else. There might be something specific in the upgrade documentation that could explain more. There also might be changes or new features that you may care about.
Geoffrey Clemm
commented Mar 07 '14, 2:43 p.m.
| edited Mar 10 '14, 1:15 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To understand this, backwards compatibility states that a version n client can talk to a version n+1 server. But the distributed accept/deliver operation is a server-to-server operation, and a version n server cannot (in general) talk to a version n+1 server (except for specific use cases, where, for example, the OSLC protocol is used to provide version independence). So if you have 4.0 client, it can talk to both a 4.0 and 4.0.5 server, but if you attempt to accept/deliver changes between a workspace on the 4.0 server to a stream on the 4.0.5 server (or vice versa), that effectively is asking the 4.0 server to talk to the 4.0.5 server.
Hi Geoffrey,
What I am trying to do is just copy the stream/component data from 4.0 system to 4.0.5 system.
I get the version mis-match error while trying to do so. However based on your explanation I guess I should be able to atleast accept the incoming changes from 4.0 in 4.0.5.
Right ?
You have to upgrade in order to use distributed. The changes to distributed between 4.0 and 4.0.5 are incompatible with each other.
Geoffrey Clemm
commented Mar 10 '14, 1:17 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note: I've edited my earlier comment to indicate that either an accept or a deliver between a workspace/stream on one server and a workspace/stream on another server requires a server-to-server operation.
and to clarify your stmt.. the .40 server can talk to the 4.0.5 server (n-1 to n)
but the 4.0.5 server cannot talk to the n-1 server n to n-1 is not allowed)
Distributed SCM requires server 1 (n-1) and server 2 (n) to talk in both directions.
Geoffrey Clemm
commented Mar 10 '14, 5:13 p.m.
| edited Mar 10 '14, 5:54 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A 4.0 server cannot in general talk to a 4.0.5 server. "n-1/n compatibility" only applies to client/server, not to server/server).
when u do the friends config .. 1 way works, the other doesn't
Geoffrey Clemm
commented Mar 10 '14, 5:59 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, I should have been clearer what I meant by "talk" ... being a "friend" is not sufficient to support the SCM distributed accept/deliver operation. So the fact that a CCM application can be a friend of another CCM application does not imply that it can do SCM distributed accept/deliver operations with that other CCM application (i.e. the SCM accept/deliver operation is more stringent about version compatibility than the "friend" operation).
showing 5 of 11
show 6 more comments
|
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.