Re: EDi 9.1 and eGit

The question about iProjects and 1 to 1 mapping…

I’m not familiar with eGit but I use/implement/train in RTC for i so I’ll try to keep my remarks generic.

First you can have as many iProjects as you want, as long as they have unique names, similar to what Paul mentioned.
Paul was breaking his up by content, but you can also break them up by library, sourcefile (done this to reduce number of members in an iProject), or version of the software.

For example I have 3 versions of the software I’m working on, so I have 3 iProjects with the pretty much same members and the iProject name reflects the version.
Each iProject contains all the members as that is how RTC wants to work, the sparse loading option still doesn’t work quite right.
The gotcha is in RTC the iProject names become subfolders in the stream if they don’t match the component name.
During the build that all goes away and I can control the build library by the iProject and have a different target library using the same build.
But it gets messy if these versions aren’t persistent, like a hotfix versus a customized version for a specific customer.
Not sure if there is any link to the iProject name and structure in git.

The other way is separate eclipse workspaces, so there is an eclipse workspace for each of the three versions and each eclipse workspace has it’s own sandbox so you can have the exact same iProject name (same as the component in RTC) and you show workspace location in RDi so you know which one you are working on. When you want to switch to a different version you switch workspaces and this model is much easier now that you can export or import preferences.
The customer I first implemented this with we created a template workspace and they copy it and change name when they start a new project and they have quite a few active projects, just checked 47 open projects today.
In this model this customer also uses multiple ‘repository workspaces’ for each programmer comparable to a git repository and they have a specific stream for the project like a central repository, but then they have the ‘production’ stream where changes go when they go to production and the project based artifacts all go away. Then those changes get accepted back into all the open project streams and merged if needed to the work going on there.

You could also use one ‘repository workspace’ for multiple iProjects by changing the target stream of the repository workspace and also the linked iProject but that gets messy fast in pending changes view with all the changesets and work items (tasks).

Hope this gave you some ideas that could apply to git

Jeff Tickner
Arcad Software.