Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

How to have the same project open on two repositories

We have two repositories - test and production. We have the same projects on both repositories. To differentiate, I added the word "Test" to the end of the project names on the test repository. Unfortunately, when I am logged into BOTH repositories, RTC is confused and still sees the projects as the same. What do I need to change to make RTC see the projects separately? These images will illustrate what I mean...

Logged into Production:

http://www.madmartian.com/special/work/Repository1.jpg

Logged into Test:

http://www.madmartian.com/special/work/Repository2.jpg

Logged into BOTH:

http://www.madmartian.com/special/work/Repository3.jpg

What it SHOULD look like when logged into BOTH (PhotoShopped):


http://www.madmartian.com/special/work/Repository4.jpg

0 votes



9 answers

Permanent link
Is the test server a clone of the production server? Connecting to two repositories that have the same repository ID is not supported.

0 votes


Permanent link
No. They're not even using the same type of database. The project data was transferred from one repository to the other. Likely the two projects have the same ID somewhere, but I can only edit the name - I can't find anyplace to edit a project ID, unless it's buried somewhere in Configuration or Configuration Source.

0 votes


Permanent link
No. They're not even using the same type of database. The project data was transferred from one repository to the other. Likely the two projects have the same ID somewhere, but I can only edit the name - I can't find anyplace to edit a project ID, unless it's buried somewhere in Configuration or Configuration Source.
How was the data transferred? The only reason I can think of that would cause the client to be confused with project areas is if the internal UUID is the same. It doesn't matter if the type of database is different if the data inside is a replica.

0 votes


Permanent link
The only reason I can think of that would cause the client to be confused with project areas is if the internal UUID is the same.


Right, that's what I'm saying. How do I change the ID for one of the projects? I can't find that setting anywhere.

0 votes


Permanent link
The only reason I can think of that would cause the client to be confused with project areas is if the internal UUID is the same.


Right, that's what I'm saying. How do I change the ID for one of the projects? I can't find that setting anywhere.It's an internal id that cannot be changed. Even changing the project id wouldn't help. It's tied to a repository id as well. Since both your repositories have the same id, you cannot be connected to both at the same time and expect the UI to do anything correctly.

What's the reason for having your production server cloned? Maybe there's a better way to have your setup. SCM does support distributed so you are allowed to flow change sets between different repositories (that have different id's) but the project areas would be different (just FYI and not a bad thing at all).

0 votes


Permanent link
What's the reason for having your production server cloned?


A true test server should be a clone of production.

0 votes


Permanent link
What's the reason for having your production server cloned?


A true test server should be a clone of production.True, but the question is why do you need a test server of your source control? Don't trust RTC and need to test it? ;)

0 votes


Permanent link
TEST EVERYTHING. A good motto to have. Eventually we'll be using the test server to test new versions of RTC before updating the production server.

0 votes


Permanent link
TEST EVERYTHING. A good motto to have. Eventually we'll be using the test server to test new versions of RTC before updating the production server.
Be careful with running two servers that are on different versions. Clients may update to the latest and find out they can't connect to the older server. Compatibility is only for older clients to connect to the next version of the server.

I think distributed servers would work better for your situation. You just cannot connect to a clone of a server twice. It is an unsupported scenario. However, distributed source control will allow you to deliver change sets between the two servers. Then OSLC links will allow you to associate change sets on the test server to work items on the production server. They won't be clones of each other but the change sets will be.

If you're really concerned about isolating problems to the test server, I wouldn't even connect to the test and production servers at the same time. You wouldn't want to take the chance of anything crossing over unintentionally.

0 votes

Your answer

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

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Sep 23 '11, 2:19 p.m.

Question was seen: 5,661 times

Last updated: Sep 23 '11, 2:19 p.m.

Confirmation Cancel Confirm