Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343610

Summary:	Lessons learned from RTC SCM integration
Product:	[ECD] Orion	Reporter:	Boris Bokowski <bokowski>
Component:	Server	Assignee:	Project Inbox <orion.server-inbox>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	aniefer, john.arthorne, Mike_Wilson, pwebster, remy.suen, simon_kaegi, Szymon.Brandys, tomasz.zarna
Version:	0.2
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:

Description Boris Bokowski

2011-04-21 15:19:30 EDT

I've been involved in an effort to explore various ways in which Rational Team Concert (in particular the SCM part of it) can be integrated with Orion. (Most of the work was done by the RTC SCM team.)

So far, we've explored using the existing file client plugin mechanism. This gives you a way to explore RTC SCM artifacts (work areas, components, files, folders) in the Orion navigator, as well as editing files from an RTC workspace.

After getting it to work, we realized that the following Orion features did not work anymore:
 - importing a zip file
 - site launching
 - full-text search

As far as I can see, these features require a server-side integration story. We should be working on compartmentalizing our existing server so that the various features are independent and self-contained, resulting in a number of (at least logical) servers instead of one monolithic server. Then, these individual and can talk to each other. Getting a server-side story for authentication and authorization in place that works across multiple servers is what we should be pushing on.

Not sure where this leaves us with the client-side integration story. There are a good number of cases where the client-side plugin story is still going to be needed, for example for the editor extensibility. For accessing files, I am not so sure anymore.

Comment 1 John Arthorne

2011-04-25 09:24:12 EDT

I've been trying to argue this point for awhile ;) My general philosophy on this is that the tools need to run where the data is. In a networked application, data transfer cost by far dwarfs any computing cost. So, if the "data" being operated on is a single file (editor buffer), then the tool should run on the client. If the data being operated on is a potentially large file system or SCM, then the tool should run on the server.

So where does the data live when you're working with RTC? Both Jazz and Git have the same conceptual model: the data is "checked out" of the SCM into some work area (Git working copy, Jazz sandbox). The tools then operate on the data in that work area (editing, searching, building, testing, etc). Periodically the data is pushed back into the SCM (either automatically or by direct user command). The development tools do not run directly against the SCM itself.

In both these models, the SCM server itself does not typically host the working area (although Git always has that option). For example jazz.net or github.com don't provide a working area for the tools to operate upon. This is where the Orion workspace comes in. Our server provides that "working area" where any development tools that require significant data access can operate. An Orion workspace server could still be "bundled" together with an SCM by a third party to provide a complete development environment on a single host if they wanted. Or, an Orion user could have a hybrid setup where the workspace server is on orionhub, or even a server running on their local machine, working with a third party SCM on a different server.

Comment 2 John Arthorne

2012-02-06 14:57:53 EST

This isn't a bug report.