[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] The role of source control in ALF
|
Absolutely, you need both sorts of operations:
1. Get a version of an individual file (file content is streamed over as
part of the reply), and
2. Populate an entire workspace. This would be more efficiently implemented
by pointing to a target directory and telling the SCM system "update"
(assuming it has access to the directory), as opposed to streaming all the
individual files through the SOAP interface.
It's not either/or. You can support both kinds of operations in the SCM
vocabulary.
Richard Title
AccuRev
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Eric Minick
Sent: Tuesday, March 07, 2006 11:19 AM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] The role of source control in ALF
It's certainly possible to do web service file transfers and for a
single file it makes sense. But if tools from ALF partners like
Urbancode and ViewTier are going to really take advantage of ALF and if
we ever wanted to bring CruiseControl on board, we need to be able to
tell ALF "get me all the source for this project" and get back hundreds
of megs of source, libraries, documentation, etc, etc. A web service
might be able to do this, but it's a less obvious fit. The Borland guys
do some of this in the StarTeam API, but I suspect some ALF
implementations would have to resort to using the SCM's command line
tool under the covers. To me that says that all the services have to be
able to access some place on some disk, but I'm not sure they need to
all access the same one. Couldn't data be pushed out to wherever a given
service wants it?
Let's pretend CruiseControl is ALF enabled. How would that work?
Presumably, instead of polling the SCM for changes like it does now, it
waits for check-in notification ALF. More specifically, code committed
on the SCM raises an event and ALF determines that a build should
happen. It tells CruiseControl to build project x. Lovely. Now Cruise
needs the source out of CVS. It seems to me, that it should be able to
ask a local ALF interface to deliver a module, using some branch, to
some local directory. Whether that happens via web-service or running
some commands could be an implementation choice.
Ah, but there's the rub. How is an ALF enabled metric tool going to get
to the code and build artifacts that Cruise is sitting on? Either the
the build information must go out to the tool or the tool must have
access to that same spot on the physical disk. The performance centered
approach would be to have the tool on the same box with access to the
same files, but either would work.
-- Eric
Richard Title wrote:
>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
>
>_______________________________________________
>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
