[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [alf-dev] RE: ALF Source Code Mangement Vocabulary Meeting+1-303-928-3232 id 6053141# Wednesday 10:00AM PDT - meeting minutes
|
Fair enough. I suppose then that the smaller the use case the better.
It's pretty safe to push it to the user to know what her tools support,
although it's not the most friendly thing to do. I'll admit to
occassionally get lost in trying to understand just how an ALF service
flow gets created and executed.
Just using what the WSDL exposes is probably good enough. I suppose I
was thinking there would be one CVS WSDL but in reality there would be
different versions of WSDL for different versions of a product.
Cheers,
Eric
Mark Phippard wrote:
alf-dev-bounces@xxxxxxxxxxx wrote on 05/03/2006 04:49:02 PM:
My other thought, and I suppose this is obvious, would be that we may
need a command that asks the SCM integration, "What do you support?" Or,
"How do you work?". From there we can get into interesting things like
meta-data.
Remember ALF is not dictating anything. We are trying to come up with a
recommended vocabulary. The assumption is that the WSDL for your SCM tool
would not expose any services it did not support. So you just would not
have them available when building a service flow. Likewise, the SCM
vendor is free to expose their own proprietary services in their WSDL and
those would also be available to you.
But other things are more basic. If I want a fresh copy of Project X, in
our use cases one would:
1) Create the workspace
2) Matterialize the workspace
That's fine in a lot of systems, but in CVS creating the workspace (cvs
checkout) implicitly populates it as well. Step 2 could be skipped. ALF
will need to know that.
Does it? When you are the user building the service flow, this is
something you can know.
A sub use case of diffing a workspace would be to just ask, "are there
any changes to this workspace?". Going back to CVS, getting a full
revision listing can be an expensive operation. Some versions (and only
some) of CVS have a seperate command for "are there changes?" that would
save a workflow time if there are not. Right now, integrating tools
either ignore this or solve it with a check box. Other tools are in a
similar boat. Last time I used Dimensions (feel free to correct me) from
the command line it was pretty easy to get a list of the last time each
file had changed. So figuring out if anything had changed since some
date was easy. But to get the details of those changes was considerably
more expensive.
So you are suggesting some use case that indicates if there are any local
changes? Seems reasonable.
I suspect that as we go, we'll hit more situations where some tools have
combined two concepts that ALF might otherwise assume are atomic. One
option is to have them report their behavior. The other is to make ALF
use cases at a larger grain. If instead of:
1) Create a workspace
2) Materialize a workspace
We had:
1) Create and populate a workspace.
2) Update a workspace (re-materialize)
ALF would need to know much less about the SCMs it was integrating with,
but they would be more likely to operate in a sub-optimal way. Both
approaches work fine.
I am not sure we need to be concerned about this. We are just making
recommendations for tools to follow and in the end a user still has to
build a service flow that uses these.
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
