It's all about the answers!

Ask a question

Putting Eclipse-like workspace under RTC source control


Fra Ben (11) | asked Jul 25 '19, 3:42 a.m.

Hello everybody,

I'm pretty new to RTC in general, so please bear with me :)

I have various projects developed in an IDE based on Eclipse(but not Eclipse itself), which I have put under RTC version control. A simplified version of the situation is as follows:

COMPONENT1

    eclipse_project1.1

    eclipse_project1.2

COMPONENT2

    eclipse_project2.1

    eclipse_project2.2

The idea we are following is to create a workspace associated to every RTC component, so that when a developer wants to work on the component he/she just has to checkout the component and open the corresponding folder as an Eclipse workspace.

But.... by doing so all the metadata associated to the workspace has ended up on RTC source control as well, and i am already starting to see the problem with this:

1) every time i open the workspace, some of the metadata is updated, adding noise to the changes detected

2) when another developer opens it..... there are conflicts on that metadata

What do i have to change? Should i just put some of the metadata under the ignore list and i'm set? Or is this approach inherently wrong?

Thanks in advance!

3 answers



permanent link
Arun K Sriramaiah (3.2k11943) | answered Jul 25 '19, 10:25 a.m.
edited Jul 25 '19, 10:26 a.m.
Hi Fra,

Please find the RTC SCM basic articles :


1) Client should be using a different eclipse client workspace and they should load the workspace for the first time and they could see all subesequent changes later in pending changes window.

Change sets checked in to a repository workspace can be delivered to a stream to make them available to other team members


2) If the common files are modified by other Developers, its expected to see conflict.


Please let me know does it helped or still any questions.

Regards,
Arun.



Comments
Fra Ben commented Jul 25 '19, 11:51 a.m.

Hello Arun, thanks for your answer :)

What you mean with 1) is that every different user should set up a local eclipse workspace? In other words, you suggest the following workflow?

1) User A creates the eclipse workspace he wants to track in RTC

2) User A uploads the projects in RTC, EXCLUDING workspace metadata (ignoring completely the .metadata folder)

3) User B wants to start working on that workspace and creates an EMPTY workspace on his/her machine

4) User B checks out the projects from RTC

5) User B imports the projects in his/her local workspace using Eclipse's "Import from file system" feature.


Is there not any way to share the workspace's metadata (i.e. versioning only a subset of the metadata which doesn't change every time and can then safely be versioned?)


permanent link
David Lafreniere (4.4k7) | answered Jul 25 '19, 1:58 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

I think you hinted on the answer yourself.. you would ignore the Eclipse project related metadata files. This would create an ignore file (called .jazzignore) that you would want to check-in and deliver. It sounds like you don't want these files under source control... so I would delete them, and deliver the change set to the rest of the team (to clean up the repo), then create and deliver the ignore file.


permanent link
Geoffrey Clemm (29.4k23035) | answered Jul 26 '19, 11:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jul 26 '19, 11:43 a.m.
Note: This is a comment on Arun's answer, but it is too long to store as a "comment".

One point to clarify is that the development stream (and each repository workspace) contains all the components that are needed for a given product, not just one component.
Another point is that the standard way of setting things up is to have the RTC sandbox located in the same directory as the Eclipse workspace.   Then the Eclipse workspace metadata directories/files are in the same directory as the RTC sandbox metadata directories/files, and this avoids the problem of Eclipse metadata being put under version control.
So the steps are:
(1) User A creates a stream, S, with a set of (empty) components.   
    User A creates a repository workspace, ws-A, on stream S.  
    User A creates an Eclipse workspace.  
    User A creates projects in Eclipse workspace.
(2) User A puts those projects under RTC source control.
    User A delivers those changes from ws-A to the stream.
    Note: The Eclipse workspace metadata is not put under source control, because it is outside of the Eclipse projects.
(3) User B creates a repository workspace, ws-B, on stream S. 
    User B creates an Eclipse workspace.
(4) User B loads ws-B into their Eclipse workspace.
(5) If it is Eclipse with the RTC plug-in, the "import" is automatically done by the "load" operation.   
    If this is an Eclipse-like IDE, where the load does not automatially do an import, then a manual import is performed.


Comments
Fra Ben commented Jul 28 '19, 7:47 a.m.

Hello Geoffrey, and thanks for the answer!

I'm starting to suspect we have setup things in a weird way. I'll elaborate more on that :)

What i understand from your comment is that a sandbox (i.e. the folder corresponding to the repository workspace on my local machine) should be at the same level of the Eclipse workspace. 
So every Eclipse workspace should correspond to a sandbox, and, by transitive property, to a repository workspace?

If so, well.... i made a mess: in my setup I have a single repository workspace, containing 3 components.
Each component corresponds to a separate Eclipse workspace (each containing 2/3 Eclipse projects). 
I think this is why i am encountering the metadata problem. Should I create a repository workspace for each component, or can I get out of this mess in a different way?


Geoffrey Clemm commented Jul 29 '19, 3:14 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

To keep things simple and easy, yes, there should be a 1-1 relationship between a repository workspace, a sandbox, and an Eclipse workspace.


It sounds like your repository workspace is fine (contains the components that you need).
So to get out of your mess, I would suggest first checking in any changes you currently have in any of your Eclipse workspaces, and then just deleting all those Eclipse workspaces.   Then create a new Eclipse workspace for a given repository workspace, and load that repository workspace into the sandbox of that Eclipse workspace. 

Your answer


Register or to post your answer.