[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] SCM Vocabulary - Workspaces Problem
|
Hello Vinay,
Hello Vinay,
Allow me to clarify. I don't mean to suggest that everywhere an SCM GUI is
running we also need a workspace service. You are correct that could result
in 100's of un-needed services.
Below is one of those ASCII diagrams, which might help clarify my view of a
possible architecture for SCM systems in an ALF world. In this diagram, I
show 3 end users sitting in front of SCM GUI's (which is what I think you
are calling the "client"). In this picture, I show the SCM GUI's built on
top of an SCM command-line-interface (CLI) (which is actually what I was
calling the "client"). Of course, SCM systems might or might not construct
their GUI's this way, but it is a common way to implement them. So for
example, if you do an "Add to Source Control" operation in the SCM GUI, it
might be implemented by running an "add" command. Or if you do an "Update
Workspace" command at the SCM GUI, it might be implemented by running an
"update" command. (Note that workspaces can exist on all the machines where
SCM GUI's are running, in addition to existing on the build machine).
The above paragraph, describing the boxes above the "===" line in my
diagram, describes stuff that is interactive, and not part of an ALF flow.
So I didn't put any ALF services in this part of the picture.
On the bottom left, I put an SCM Service wrapping an SCM Server. These would
be running on the machine with the SCM repository. The SCM CLI's in the top
picture would typically be communicating directly with the SCM Server (e.g.
through sockets), not going through the SCM Service. However, an SCM Service
could certainly exist here to handle various SCM requests.
(user) (user) (user)
+---------+ +---------+ +---------+
| SCM GUI | | SCM GUI | | SCM GUI |
+---------+ +---------+ +---------+
| SCM CLI | | SCM CLI | | SCM CLI |
+---------+ +---------+ +---------+
| | |
========================================================== network
| |
+----------------------------------------+
+------------+ | +-------------------+ +-------------+ |
|SCM Service | | | Workspace Service| |Build Service| |
+------------+ | +-------------------+ +-------------+ |
| SCM Server| | | SCM CLI | | Build Tool | |
+------------+ | +-------------------+ +-------------+ |
(SCM repository) +----------------------------------------+
Finally, the big box on the lower right is your build machine, where the
Build Service and Build Tool are running. So, the SCM workspace that your
build tool cares about is living on that machine. Therefore, the SCM
Workspace Service is running on that machine.
A typical service flow in this picture might be:
- SCM Server initiates the flow with a "something got promoted to a stream"
event
- Workspace Service running on the build machine receives an "Update
Workspace" request.
- Build Service running on the build machine receives a "Build Workspace"
request.
When I said the Workspace Service could be implemented by "wrapping the SCM
client", what I really meant was by wrapping the SCM CLI. I.e., the "Update
Workspace" request could be implemented by running an "update" command. (The
same command the SCM GUI would run to accomplish its update).
As to your last question: "How can ALF be possibly configured to send the
"Workspace Object" to each such SCM Client Workspace Service?". I think the
problem is not to send it to *each* Workspace Service, the problem is to
send it to the *right* workspace service. My view is that the Workspace
object needs to have enough information in it so we know what Workspace
Service to send it to. If the Workspace object has a
machine+directory-on-machine (i.e. a location), that information is
sufficient to know where to route the request. (The picture above only had 1
Workspace Service, but in general there could be > 1).
Does all this make sense?
Richard
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Nath Penmatsa, Vinay
Sent: Thursday, June 22, 2006 8:04 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] SCM Vocabulary - Workspaces Problem
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
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
