Skip to main content

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

alf-dev-bounces@xxxxxxxxxxx wrote on 05/25/2006 03:02:18 PM:

> Does this make sense?

I do not think it makes sense in the context of ALF.  I think what you are 
describing is how an SCM tool could use web services as the protocol for 
client and server.  If that is something you want to do for Accurev, go 
ahead, you will be ahead of the game.  I think that is beyond what we are 
talking about with ALF.

> In the above picture, you have the (one) CCWeb server running on the 
server-
> side and presenting a single URL (for instance
> http://myserver.mycompany.com/ccweb) to all the clients. The clients, 
which 
> are browser-based, go to that URL and login. Once logged in, they can do 
any
> ClearCase operations they want, including creating (local) workspaces, 
> updating them, etc. 
> 
> In this picture, workspace management (e.g. writing files on the client 
> machine) is accomplished by a signed Java applet that is downloaded from 
the
> server as part of the HTTP-based interface, and launched from the 
browser. 

I think your ClearCase example is off the mark.  Because really, to be a 
"like" comparison, the client browser would have to be causing these 
actions to happen on some arbitrary third machine.  Neither ClearCase, nor 
the architecture you describe can handle that.  The only architecture that 
can handle that is one where some agent/server/service (choose your term) 
is already running on that arbitrary third machine so that the SCM server 
can initiate a request to that machine and send it the files.  Some SCM 
tools (I think Dimensions for one) might have this architecture option. If 
they do, they can still use it in our ALF scenario. 

> Getting back to ALF and web services, I just don?t think running a web 
> server on every SCM client machine, and having that server turn the 
requests
> into SCM commands,  is the right architecture for the web. 

Maybe we just have a fundamentally different idea as to what ALF is about. 
 Even in the largest organizations, the number of these machines should be 
relatively small.  Only centralized servers that are running builds, 
tests, security scans etc. should need this service.  Those servers will 
likely already be running the ALF services for those functions.  Adding 
SCM to the mix is not placing a burden on the process.

> My goal here is to come up with the *right* implementation architecture 
for 
> SCM in ALF, not just what?s most expedient. Wrapping existing SCM CLI?s 
with
> a Tomcat server on each client seems to me expedient but architecturally 
wrong. 

I think this is the chief area of disconnect.  I, emphasis on I, do not 
think ALF is about defining SCM services, or Build services, or Testing or 
Issue Management.  It is about defining how these already existing tools 
can talk to each other by initiating events and exchanging data. 

If we were starting with Build instead of SCM, would any of us be 
suggesting that we need to make a system to that the Java or C compiler 
could compile files that did not exist on local disk storage?  I would 
assume not.  In the same vein, we should not be suggesting that existing 
SCM tools need to behave differently than they already do.  This is 
supposed to be about providing a web services based API layer above the 
existing facilities.

Finally, in the spirit of trying to bring us back together, I'd just like 
to reiterate that all we are doing is describing some theoretical base 
behavior for an SCM tool.  Any given SCM tool is always free to innovate 
and provide different services that do more.  If we set the bar too high, 
tools are just not going to participate.  Either that, or we will spend 
all of our time engineering workarounds for tools like CVS and SVN instead 
of providing innovation in our own products.

Mark



_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________


Back to the top