Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [alf-dev] SCM Workspace discussion

It could. And in any case that could be an option.

The issue is that if ALF specifies the local path, then the ALF service
flow has to assume knowledge of what file paths the tool(s) and the SCM
client(s) have access to.  Either

1. it gets hard coded in an ALF service flow. This is likely to be
inconvenient if I want to move things around on my network or
re-configure a machine. 

Or

2. we have to provide some other service that can hold the configuration
as a configurable named property.  This is not an unreasonble idea since
it could provide a some centralised configuration.  

A local service configuration is a possibly useful for other reasons but
it could be we don't require it since we can get the benefit using a
technique like 2. which looses locality but has other advantages.

Tim



-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mark Phippard
Sent: Thursday, May 25, 2006 11:36 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] SCM Workspace discussion

alf-dev-bounces@xxxxxxxxxxx wrote on 05/25/2006 02:30:21 PM:

> If we go with A then we still need to figure out how we coordinate the

> file location with the tool or tools that need to access it.  The 
> system needs to be configured so that the tool service and the SCM 
> client service share a file system.  It could be a local path or a 
> shared file path depending on the preference of the ALF application 
> designer dn the requirements of the scnario.  Possibly the SCM client 
> service is configued with a root storage area from which it can 
> dispense folders allowing more than one "workspace".  The service flow

> can request one, the service can return the path as a string, which 
> ALF can give then give to the tool.  The string is essentially an 
> opaque "workspace" ID to ALF.

Why wouldn't the SCM "get" service just accept (among other things) a
string literal that is the path to "get files to".  Such as
"C:\workspace"

And then the Build service perhaps accepts (among other things) a string
literal that points to the same source location. Such as "C:\workspace".

I am sure there are some good reasons to make this more advanced, but
perhaps you can explain them?  Let's say you are doing nightly builds
and you want the path to be "C:\workspace\N20060425".  It seems like it
would make more sense that there be some code that runs in ALF or the
service flow that creates this value and then just hands the string to
the SCM and Build service.  Rather than those services needing to
provide such a service.

Mark










________________________________________________________________________
_____
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs. 
________________________________________________________________________
_____
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev

**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.



Back to the top