[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] The role of source control in ALF
|
Again, why do you think it is a fundamental problem to return file-contents
in a SOA? It's just a stream of bytes.
By the way, another SCM-related standard worth looking at, in addition to
JSR 147, is WebDAV DeltaV (see http://www.webdav.org/deltav/ ). Again, it's
not SOAP, so it's not directly usable by ALF. But some of the ideas might be
useful. It's an extension of HTTP to support versioning. It does have a
"GET" and "PUT" operations to obtain/update file/version contents.
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:51 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] The role of source control in ALF
Scott,
Thanks for replying. I will take a closer look at the requirements, I had
only scanned them in the past.
I didn't mean to imply that source control plays no role in ALF. For
example, I can see the source control system sending events to ALF, such
as when files are committed, so that ALF can perhaps initiate a service
flow of some kind.
What I was getting at is an issue that the POC demo actually raises. A
lot of the tools and areas that we are talking about for ALF operate on
source code. Would we ever envision a "GET" request delivering the
results via an SOA? I do not even know how that could be done.
WS-Attachments maybe? This seems impractical, so it seems like either all
of these services are going to need access to the same physical location,
or these tools are going to still need their own point to point interface
to the source control system in order to get the source code.
So perhaps my points were two-fold:
1) Source control-related vocabularly probably needs to focus more on
what types of events a source control system should raise. Since this
scenario obviously makes sense and can provide a lot of value.
2) When trying to explain ALF to someone, maybe it would make sense to
look for other areas to focus on other than source control?
Related question:
Would we envision a source control system being able to ask questiosn/seek
approval via ALF? For example someone wants to checkout or check-in some
source code. Could the source control system send a request to ALF to see
if it was OK? For example, maybe the related issue has not been approved
yet or something like that.
Mark
alf-dev-bounces@xxxxxxxxxxx wrote on 03/07/2006 09:38:42 AM:
> I think you have to separate out a bit the use cases that are modeled in
the
> POC and the long term possibilities integrating SCM and other tools.
Issue
> tracking is probably the most obvious: SCM integrates with ITS tools to
> version and manage change packages/change palettes/change sets (insert
your
> tool's nomenclature here) that address specific defects across multiple
> release branches. But for many of the other tools in the ALM suite, we
think
> there are plenty of cases where objects need to be properly versioned
and
> managed at the infrastructure level, and see SCM as fundamental to the
> success of ALF-enabled workbench.
>
> The POC though has really only modeled the most superficial SCM use
cases,
> which I think reflects more urgent short-term priorities for the project
and
> does not properly model the role of SCM and the SCM repository in the
> overall process flow. Richard Title here at AccuRev has submitted some
cases
> to build out the story a bit (and attempted to map out some common
> vocabulary among several leading SCM tools)--these are still pending
review
> from the requirements group--but I think these will be a start to better
> representing the role of SCM in the suite.
>
> I believe Kelly has posted these cases on the ALF requirements
site...take a
> look and see what you think. We'd welcome some additional feedback and
agree
> wholeheartedly that the SCM needs some further attention in the ALF POC.
>
> Best, Scott
>
>
>
>
> Scott McGrath | Senior Product Manager
> AccuRev, Inc. | www.accurev.com
> 781.325.0652w | 617.834.2339m
>
>
> -----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
>
>
>
>
>
>
> _______________________________________________
> alf-dev mailing list
> alf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/alf-dev
>
>
____________________________________________________________________________
_
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email
> Security Management Services powered by MessageLabs.
>
____________________________________________________________________________
_
____________________________________________________________________________
_
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
