It's all about the answers!

Ask a question

How to have the same project open on two repositories


Mike Shkolnik (9808160143) | asked Sep 23 '11, 2:19 p.m.
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

9 answers



permanent link
Tim Mok (6.6k38) | answered Sep 23 '11, 2:55 p.m.
JAZZ DEVELOPER
Is the test server a clone of the production server? Connecting to two repositories that have the same repository ID is not supported.

permanent link
Mike Shkolnik (9808160143) | answered Sep 23 '11, 4:19 p.m.
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.

permanent link
Tim Mok (6.6k38) | answered Sep 23 '11, 4:46 p.m.
JAZZ DEVELOPER
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.

permanent link
Mike Shkolnik (9808160143) | answered Sep 23 '11, 5:45 p.m.
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.

permanent link
Tim Mok (6.6k38) | answered Sep 23 '11, 6:17 p.m.
JAZZ DEVELOPER
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).

permanent link
Mike Shkolnik (9808160143) | answered Sep 23 '11, 6:24 p.m.
What's the reason for having your production server cloned?


A true test server should be a clone of production.

permanent link
Tim Mok (6.6k38) | answered Sep 23 '11, 6:49 p.m.
JAZZ DEVELOPER
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? ;)

permanent link
Mike Shkolnik (9808160143) | answered Oct 06 '11, 8:29 p.m.
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.

permanent link
Tim Mok (6.6k38) | answered Oct 07 '11, 9:08 a.m.
JAZZ DEVELOPER
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.

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.