<lurkmode off/>
Having done some proprietary work with the SCC API in the past, the key is
that using the SCC lets you integrate into the Microsoft Toolset. As with
anything, over time it's become the defacto version control interface into
many tools. Accesibility to all the tools that use the SCC API would be the
big win for Subversion for it to gain corporate acceptance.
Since it provides only about 12 basic functions (checkin / checkout /
undocheckout, etc..) the problem of mapping what those mean is somewhat
mitigated. It does help as well that Subversion thinks about versioning
directories, which CVS did not. But the lack of openness of the SCC means
having to decide if it's ok to have closed boundary layer between Microsoft
and Subversion which is what the CvsScc work was all about.
Using the MS COM interfaces won't get you integrated into the toolsets, only
into the SourceSafe object model, which is not where you want to go. Having
heard mention of having Subverion COM interfaces would provide the
equivalent access to Subversion. It would be cool if I could replace my
build scripts which use SourceSafe by changing the COM interface code to
Subversion.
<lurkmode on/>
Paul D'Anna
pdanna@iname.com
----- Original Message -----
From: "Eric W. Sink" <eric@sourcegear.com>
To: "Sander Striker" <striker@apache.org>; "Brian Behlendorf"
<brian@collab.net>; <dev@subversion.tigris.org>
Sent: Friday, December 07, 2001 6:58 PM
Subject: Re: Microsoft's SCC interface
>
> The SCC API is still present in Visual Studio.NET. Our
> product (SourceOffSite) has made use of it for quite
> some time.
>
> I speculate that the API will be just as awkward with
> svn as it is with CVS.
>
> The API itself is, shall we say, not the highest quality
> API Microsoft has ever developed. :-)
>
> And, as the previous poster mentioned, the resulting code
> cannot be open source while remaining in compliance with
> the NDA.
>
> --
> Eric W. Sink
> eric@sourcegear.com
> http://www.ericsink.com/
>
>
> ----- Original Message -----
> From: "Sander Striker" <striker@apache.org>
> To: "Brian Behlendorf" <brian@collab.net>; <dev@subversion.tigris.org>
> Sent: Friday, December 07, 2001 8:50 PM
> Subject: RE: Microsoft's SCC interface
>
>
> > > From: Brian Behlendorf [mailto:brian@collab.net]
> > > Sent: 08 December 2001 03:40
> >
> > > When talking about Subversion with corporate types (yes, it may seem
> > > premature to start doing that, but hey, people are getting excited
about
> > > it) the question of integration with Windows development tools comes
up.
> > > Sure, there's DAV and all that. But most Windows dev tools (and
various
> > > other commercial ones, it appears) support an older API called "SCC" -
> > > here's a link to discussions about the protocol:
> > >
> > > http://members.home.net/preston/cvsscc.html
> > >
> > > It's not a link to the protocol spec itself, since it's only available
> via
> > > NDA. The author states,
> > >
> > > "The main problem is that the SCC interface was not designed for
> anything
> > > like CVS. The mapping between CVS semantics and the SCC interface is
> > > awkward at best."
> > >
> > > I wonder to what degree Subversion makes for a better map. I'm sure
> there
> > > are some things which neither CVS nor SVN do for good reasons
(exclusive
> > > locks, for example) but I'm curious whether it could be made to work.
> If
> > > so, we might be able to get fundage to implement it.
> > >
> > > Has anyone looked at this before?
> >
> > It came up in an irc or im discussion. It is unclear what MS will do
with
> > this SCC API in Visual Studio 7/.NET. It doesn't sound very appealing
to
> > me to implement against an API that could go away under an NDA license,
> > which will mean that we can only provide binaries.
> >
> > I'd rather see some talks with MS to find out where SCC is heading in
> > Redmond.
> >
> > > Brian
> >
> > Sander
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:51 2006