RE: [alf-dev] The role of source control in ALF

["Richard Title" <rtitle@xxxxxxxxxxx>]

I can certainly envision use cases where an ALF-enabled tool will want
access to files under source control (or more precisely, the stream-of-bytes
that represents the content of some version of a source-controlled file).

An example would be a test tool, like Mercury WinRunner or Rational Robot,
where the tests themselves (scripts in some language) are stored in source
control. The test tool may well want to do "get" or "put" (or
"checkout"/"checkin" or whatever we call those operations) on the files.
I can think of many other similar use cases. 

There is no reason why file contents (just a stream of bytes) cannot be
embedded in a SOAP message.

You are correct that defining SCM operations down to that level is complex.
And standardizing this set of operations across a variety of SCM systems is
a challenge. But it is by no means impossible. As an example, I refer you to
the JSR 147 document for an attempt to come up with a standardized API for
SCM operations ( see http://www.jcp.org/en/jsr/detail?id=147 ). Since it's
an object-oriented Java API, it's not easily transformable into a web
services interface. But it's an interesting and well-defined SCM API worth
looking at.

I'll send out mail at a later time with some of my ideas for a standard SCM
vocabulary for ALF.

Richard Title
AccuRev


-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark Phippard
Sent: Tuesday, March 07, 2006 9:15 AM
To: ALF Developer Mailing List
Subject: [alf-dev] The role of source control in ALF

Watching the POC demo and writing my web service for Subversion made me 
really start to question the role of source control in ALF.  I am sure 
that there will be cases where having it supported will be useful, and 
having a service interface to a source control tool cannot hurt, but I 
wonder how well it is really going to work in the real world.  I think the 
whole concept of an SOA kind of falls apart if ALL information that needs 
to be exchanged cannot be done via the service interface.  In the case of 
source control tools, the information that needs to be exchanged is 
ultimately the source itself.  Do you eventually envision defining a 
vocabulary or whatever, where the source control service would actually 
deliver the artifacts via the web service?  That seems like it would be 
hard to do and probably be overly resource and network intensive.

If all you can do is send an instruction to a source control tool telling 
it to get source to some folder accessible via the web service that is 
going to be very limited in how you can deploy and build your solution and 
service flows.  Take the POC demo as an example.  You are doing a GET of 
the source code so that you can build it, test it and scan the source for 
security bugs.  This only works in the POC demo because all of the 
services have access to the same location.  How is ALF going to move 
beyond that in the real world?  Are users going to have to have all of 
their source-related services deployed on the same server?  It seems like 
in a real world deployment you are going to wind up just using the 
features that are built into OpenMake, or Ant or whatever build tool is 
used to let it go get the source from the source repository and then build 
it. 

Is there a trick up your sleeve that I am not aware of, or is this always 
going to be a real issue?  If it is, then I think we need to start 
defining alternate reasons why ALF is going to provide value.  The problem 
with the POC demo is that there are probably hundreds of tools already out 
there that do the same thing much easier.  The only parts of that demo 
that you could not do with a simple Ant script are the parts related to 
the issue tracker and even that could be done relatively easily if the 
issue tracker had Ant integration.

Thanks

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