RE: [alf-dev] SCM Vocabulary - Workspaces Problem

["Nath Penmatsa, Vinay" <vinay.nath.penmatsa@xxxxxxx>]

Hello Richard,
  Can you clarify if I interpret your proposal correctly-

1. I would like to have a central build, probably once a day and
triggered manually. In this case, a flow can be configured in ALF, which
involves invocation of "SCM Service" and later a build. SCM clients do
not come into picture here. The storage area can be in one central
system which stores the archives/build results.

2. I would like to have an on-demand local build of my workspace where
an SCM client is installed. As part of the service flow, I would define
a call to "Workspace Service" and this flow can be initiated by an event
from the SCM client tool to ALF. The storage area is likely to be on
this client system itself and utilized only by the dev environment on
this client system.

Now questions regarding (2) if the above interpretation is correct -
a. Do you mean that in every client system where the SCM client resides,
we need the Workspace service running? There may be hundreds of such
clients.
b. How can ALF be possibly configured to send the "Workspace Object" to
each such SCM Client Workspace Service?

Regards,
Vinay 

-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Richard Title
Sent: Wednesday, 21 June 2006 10:05 PM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] SCM Vocabulary - Workspaces Problem

My view is somewhere in between what Tim said and what Mark said. :-)

I think it's a useful breakdown of SCM functionality if we define it as
2
services: A "SCM service" and a "Workspace service". The "SCM Service"
would
typically be implemented by wrapping the SCM server, and would typically
live on the machine where the SCM repository lives. The "Workspace
Service"
would typically be implemented by wrapping the SCM client, and would
live on
the machine where the workspaces (and SCM clients) live.

A GET would be implemented by sending a Workspace object to the
Workspace
Service. 

Workspace objects might be the output of other operations. E.g., if the
SCM
service starts a service flow by saying "hey, a Promote operation just
happened", it might output a set of Workspace objects which are affected
(i.e. need update).

Where I agree with Mark is that I see the *implementation* of both the
SCM
Service and the Workspace Service as being the domain of the SCM
vendors. I
see ALF as providing the *vocabulary* for both services, with the SCM
vendors actually implementing them. Most likely, in the initial cut,
vendor
X's Workspace Service would only be able to deal with Workspace objects
emanating from vendor X's SCM Service. (Because the actual
implementation of
a GET operation would involve private communication with its matching
SCM
server, on a channel through which the files actually flow). Down the
road,
if we do a good job standardizing and agree on various details, we might
achieve inter-operability of Workspace Services and SCM Services across
vendors.

Make sense?

I look forward to discussing this more in 1/2 hour. :-)

Richard Title
AccuRev



_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev