Migrating SCM from one repository to another
I've read a few articles on flowing changes cross repositories using distributed SCM (https://jazz.net/library/article/535). The procedure seems to be:
1) is there any requirement on server versions (like, do they both have to be at the same level, if not, which must be the higher level)?
2) When I deliver the changes from Server2 to Server1, do I get all of the "history" of every changeset that was done in Server1? Or will I basically get just the current contents of the stream on Server1?
3) Any "gotchas" or problems that people have hit doing this?
Thanks,
Susan
-
Enable distributed source control for two servers; for example, Server1 and Server2.
-
Create a repository workspace on Server2 from the contents of a stream on Server1.
- Create change sets in the new repository workspace and associate them with work items on Server1 or Server2.
- Deliver changes from Server2 to Server1.
1) is there any requirement on server versions (like, do they both have to be at the same level, if not, which must be the higher level)?
2) When I deliver the changes from Server2 to Server1, do I get all of the "history" of every changeset that was done in Server1? Or will I basically get just the current contents of the stream on Server1?
3) Any "gotchas" or problems that people have hit doing this?
Thanks,
Susan
3 answers
the servers must be level compatible.
version 3 cannot accept connections from non-version 3 clients.
version 4 can accept both V3 and V4 clients.
I cannot answer the other questions.. we looked at DSCM, but it takes a full server deployment where-ever you want a second system. web server, deb server, maybe license server. backup and recovery of all that.
we had removed local IT staffs from remote offices, so this made the infrastructure harder to support.
and then the teams wanted to do autonomous operations, workitems, etc on the local server, but then you run into no workitem linking across servers, and it goes downhill from there..
version 3 cannot accept connections from non-version 3 clients.
version 4 can accept both V3 and V4 clients.
I cannot answer the other questions.. we looked at DSCM, but it takes a full server deployment where-ever you want a second system. web server, deb server, maybe license server. backup and recovery of all that.
we had removed local IT staffs from remote offices, so this made the infrastructure harder to support.
and then the teams wanted to do autonomous operations, workitems, etc on the local server, but then you run into no workitem linking across servers, and it goes downhill from there..
1) The article you refer to has an appendix regarding the compatibility between servers. The short story is there is no guarantee that different versions will work so use the same to ensure compatibility. You can try different versions but you'll be stopped if performing a distributed operation and the servers aren't compatible.
2) You will get as much history as is required. When you flow the component to the other server, it's entire configuration will be replicated. Anything that does not exist in that configuration will not be replicated. Just work as normal after initial replication because change sets will get replicated as needed.
3) First replication can take a while so be patient. If an error occurs, you can retry and it will continue replicating. Once replication is done, remember to set the component permissions on the target server because it will be set to private for the user that performed the replication.
2) You will get as much history as is required. When you flow the component to the other server, it's entire configuration will be replicated. Anything that does not exist in that configuration will not be replicated. Just work as normal after initial replication because change sets will get replicated as needed.
3) First replication can take a while so be patient. If an error occurs, you can retry and it will continue replicating. Once replication is done, remember to set the component permissions on the target server because it will be set to private for the user that performed the replication.