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
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.
Copying (using distributed) from 4.0 to 4.0.5 is included in the backwards compatibility statement. It is a use of the distributed feature, hence the error about incompatible versions.
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,
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.
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)
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
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).