Guess RTC is a total different story as it is much more than just version control like Git is (hence lacking any concept of builds and link with the iSeries objects).
While eGit does it job now it lives completely seperate from your iSeries environment... parrallel to your actions in Git you therefore need to push the correct changes to your iSeries as well (in your personal library), and also move them into the production library which is similar to a Git push in your master branch.
This concpet of non-linked files makes it very difficult to keep branches in synch with your iSeries and objects you'll run.
________________________________________
From: WDSCI-L [wdsci-l-bounces@xxxxxxxxxxxx] on behalf of Jeffrey Tickner [jtickner@xxxxxxxxxxxxxxxxx]
Sent: Thursday, August 06, 2015 21:29
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] 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.
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/wdsci-l.
midrange.com
