One thing that occured to me:  Another possibility is to the use the javahl code base that ships with Subversion, run it through the IKVM.NET (http://weblog.ikvm.net for the latest bits) ikvmc compiler, and then utilize the resulting assembly as the interface into SVN.  It seems that one key advantage to this approach is the fact that the javahl bindings are more likely to be up-to-date with the latest features of SVN.

On 9/14/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
2006/9/14, M. David Peterson <[EMAIL PROTECTED]>:
> Hey Seo,
>
> >> For SVN access, I am willing to write a VC plugin using .NET
> subversion libraries like NSvn.
>
> I need this for other projects, and plan to take a first stab at it before
> too long.  If/When I do (If would be if you beat me to the punch, which for
> obvious reasons would be fine by me :) I will point you to it.

I think there's some misunderstanding here.

I intend to write a Trac-specific VC plugin which provides
IRepositoryConnector API for SVN. I do not intend to write a
full-blown pysvn replacement. So I wonder why you "need this for other
projects", as it won't be useful outside Trac.

In my opinion, writing a pysvn replacement would be a bit insane thing
to do. pysvn is very big and comprehensive library ranging from
low-level to high-level. On the other hand, Trac VC API needs only a
little bit of information from version control plugins, which can be
done without following intricate details of Subversion C library and
APR(Apache Portable Runtime) too closely.

Anyway, if you have something to test, don't hesitate to let us know.

Seo Sanghyeon
_______________________________________________
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354
_______________________________________________
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to