At 11:29 PM 4/18/2000, Win32 M$ wrote:
>Hi Noel,
>
>>[EMAIL PROTECTED] on 04/18/2000 11:45:52 PM
>> >Also, with SCC API you need to sign NDA with M$, and then it is not Open
>> >Source anymore. It doesn't help :(
>>
>>I don't understand. Doesn't this mean that CVS support for SCC is
>>impossible?
>>Do you have a link to their NDA contract?
You have to telephone MS and speak to the project manager for Visual
SourceSafe about the NDA. This is not possible via web or email. Preston's
project page (http://members.home.net/preston/cvsscc.htm) gives details.
Looking to the future, I would guess that the SCC API will disappear in a
future release, since MS has announced that in Visual Studio 7, DevStudio
is disappearing and VC++ is being integrated into the same Visual Studio
environment that hosts their other languages (VB, VI, VJ++). See
http://www.microsoft.com/presspass/press/2000/Apr00/VCDCpr.asp. This would
suggest that their direction is the SCC COM interface. What this does for
third-party products that use SCC API is anyone's guess.
>Of course CVS support for SCC is possible, and in fact there is a project
>like that right here:
>
>http://members.home.net/preston/cvsscc.html
>
>To make a long story short: there are two SCC inerfaces:
>1. SCC COM - documentation available, no need NDA, and it's full of bugs,
>2. SCC API - M$'s top secret, actually works and require NDA.
Also many applications, such as MS DevStudio (the VC++ IDE) support SCC API
but NOT SCC COM, so anything that will talk to DevStudio MUST support the
secret SCCAPI.
As someone who's trying to contribute to the effort (making WinCVS work
with Preston's CVSSCC interface), I can report that things are going slowly
at my end, largely because I am having to figure out WinCVS's convoluted
design (WinCVS is a very nice application, but it's not simple to
understand and modify with the assurance that I'm not breaking things) and
because of some irregularities that arise because WinCVS was not originally
designed as a COM Automation server.
Example: if you bring up the GUI via its Out-Of-Process Server interface,
you can't get that instance to respond interactively because it's
programmed with a Doc/View paradigm but since there is no persistent
"document" object, there is an awkwardness when the CApplication is
starting, so a non-functioning MainFrame menu appears and the explorer
interface is disabled. I have worked around this problem, but it's ugly and
I am trying to find a cleaner solution. This is but one of many awkward
bits in bridging WinCVS and DevStudio.
Other problems arise from the complication of interprocess communication
among three programs with minimal documentation: something in the
communication between DevStudio, CVSSCC, and WinCVS times out so that in a
time-consuming CVS operation message boxes keep popping up from DevStutio
warning the user that the Version Control system is not responding.
I am working on this on evenings and weekends when I can find the time
outside of my real work and spending time with my family, so I am not
spending as many hours on this others might wish. I also sidetracked myself
from the CVSSCC project for a while to integrate Tony Hoyle's ntserver
protocol into WinCVS. I expect my own contributions to CVSSCC to proceed
steadily, but slowly, in the foreseeable future.
Everything that needs the MS NDA is already complete and Preston did an
excellent job of separating the two pieces and documenting the CoWorker
interface between the pieces, so volunteers who want to work on the Open
Souce part can simply write to Preston's CoWorker interface.
>In fact it seems that the NDA part can be 'excluded' from the rest of the
>code, in a way that it forwards the SCC API call to somewhere else. And
>indeed CVSSCC project claims that this is done, and all it's left is to
>hack WinCvs a bit to make it doing the apropriate job. And here is where
>the current development seems to stuck:
>1. To hack WinCvs is not that easy (done that & know what I'm talking
>about. It's HUGE!)
Amen! See above...
>2. To map SCC interface to CVS is not easy. SCC is more suitable for
>reserved checkouts.
I have spent much time scratching my head and asking how I should treat
this awkwardness.
Finally, I find that WinCVS is such a good program, and it's so easy to use
it as a separate process from DevStudio that most of the motivation for my
continuing to work on the SCCAPI interface is merely pig-headedness and the
sense that I will learn interesting things about COM from the project.
So the bottom line is that nobody should be holding his/her breath waiting
for CVS SCC to be a functional product, but there are people working
(slowly) at it.
For people who want something soon, it's great that Jerzy produced an
alternate solution that works on a much more limited problem domain, and
only on one product, but which works today!
Jonathan Gilligan
