We are a group of 3 students who are working on integrating Subversion into
Visual Studio. NET for our final year project at Oslo University College.
Some of you may remember the initial posts made to the list about this a
couple of months ago. Since then, CollabNet has agreed to fill the role of
employer for our project.
After a period of exams and of doing administrative stuff related to the
project(academia...:-|) we are now at the stage where we can actually begin
to write some code(woohoo!). Since the addin itself is going to be written
in C#, we need to make the Subversion client API available to .NET
languages. We believe there are three alternatives for doing this:
o SWIG - From several discussions on this list, we have received the
impression that SWIG is the preferred way to wrap the Subversion client API.
However, for us this approach has several disadvantages:
- .NET/C# is not (yet?) a supported target for SWIG. This means we might
have to implement this support ourselves, and this is probably not
achievable within our timeframe.
- None of us are familiar with SWIG(Ok, this is not a major problem, but
- The existing SWIG bindings for SVN doesnt appear to be working too well
on Windows yet. Is this related to the fact that SVN on Windows still is
just a set of static libraries?
o P/Invoke - P/Invoke is the standard .NET mechanism for accessing unmanaged
APIs. However, it requires us to mirror every type and every function from
the Subversion API that we need to access in C#. Given the size of the API,
this is: a) A PITA to implement and maintain. b) A pretty fragile solution.
P/Invoke also requires dynamic libraries, which SVN doesn't yet have on
Windows(any timeframe on this?)
o Managed C++ - MC++ allows us to write mixed assemblies - eg, assemblies
containing both managed and unmanaged code. This means we can write a single
DLL which links to the SVN .libs, and that exposes a managed interface for
consumption by managed languages. This approach works equally well with both
dynamic and static libraries.
Currently, we are leaning towards the last solution, but we would be very
interested in hearing input from other people on this.
Arild Fines, Kristin Borud and Per Krämer
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Feb 3 19:04:59 2003