It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×1,220

question asked: Jun 13 '13, 3:56 a.m.
question was seen: 4,461 times
last updated: Jun 13 '13, 4:39 p.m.

Related questions

Migrating SCM from one repository to another

0
Susan Hanson (1.6k●2●201●194) | asked Jun 13 '13, 3:56 a.m.
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. Enable distributed source control for two servers; for example, Server1 and Server2.
  2. Create a repository workspace on Server2 from the contents of a stream on Server1.
  3. Create change sets in the new repository workspace and associate them with work items on Server1 or Server2. 
  4. Deliver changes from Server2 to Server1. 
I had just a couple quick questions:

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

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
sam detweiler (12.5k●6●195●201) | answered Jun 13 '13, 8:23 a.m.
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..
0
permanent link
Tim Mok (6.6k●3●8) | answered Jun 13 '13, 11:49 a.m.
JAZZ DEVELOPER
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.
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jun 13 '13, 4:39 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
WRT question 2, one way to get a feel for what change sets will be replicated: everything in the change set history of the stream/workspace doing the delivery will be replicated.

Your answer

Register or 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.