[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: Microsoft's SCC interface

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2001-12-08 07:02:29 CET

Unfortunately, the VSIP program as is, doesn't expose the necessary
interfaces (and/or documentation) to implement an SCC integration
sensibly and fluidly inside the IDE. However, Jay is correct. MSSCC API
is still supported by the IDE in VS.Net.

Trying to contact the VSIP folks, &/or the MSSCC API contact alias would
be your best bet. Although, I wouldn't hold your breath, and quite
frankly you'll probably be better off writing a stand alone UI for SVN.
It'll get the semantics correct, and be easier to maintain.

Goodness knows that if the VS.Net interfaces were public, I'd probably
be working on that instead of the COM layer. :)

Bill

--
Bunnies aren't just cute like everybody supposes.
They got their hoppy legs and twitchy little noses.
And what's with all the carrots, 
What do they need such good eyesight for anyway?
-----Original Message-----
From: Jay Freeman (saurik) [mailto:saurik@saurik.com] 
Sent: Friday, December 07, 2001 9:52 PM
To: svn-dev
Subject: RE: Microsoft's SCC interface
I've talked with some people at Microsoft about SCC a while back and it
didn't look like they cared much about supporting it anymore... they've
been wanting to build something much better and hopefully will at some
point :).  It _is_ still in VS.NET, however.
The paradigm it uses is pretty weak, however.  If someone wanted to go
this route it might be a much better option to go through the Visual
Studio Integration Program and try to build a different linkage that is
more specific to Subversion.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
-----Original Message-----
From: Sander Striker [mailto:striker@apache.org] 
Sent: Friday, December 07, 2001 8:51 PM
To: Brian Behlendorf; dev@subversion.tigris.org
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
Received on Sat Oct 21 14:36:51 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.