C# API SVN - Page 1

Yop,

Quelqu'un connaitrait une API C# pour utiliser SVN, et qui ne soit pas SubversionSharp ? (jamais releasé, compile difficilement, et plante quand j'essaie d'instancier une classe "SvnClient")

mci

Ça m'étonnerait qu'il y en ait beaucoup d'autres malheureusement

hmf chui mal barré si c'est le cas :/

J'ai essayé parce que ça m'interesse aussi et j'ai aussi une "System.TypeInitializationException" à l'instanciation je vais regarder un peu ce qu'il se passe pour voir.

ah bah si tu trouves ça m'intéresse, perso ça m'a découragé et j'ai pas cherché plus loin en fait #feignasse#

Tain, je suppore pas ce genre de trucs.. Tu installes super difficilement, quand tu y arrives, tu fais le truc le plus basic pour voir, ca plante aussi... En général c'est sous linux et des logiciels libres qui font ça. Ca donne pas une bonne image au libre franchement.

Bah, souvent c'est tout bête à patcher, et si tu utilises un paquetage pour ta distribution, c'est déjà patché. Exemples:
https://bugzilla.redhat.com/show_bug.cgi?id=235546#c15
https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01011.html

Mais ici, ce n'est pas sous GNU/Linux le problème a priori. Et je suppose que le problème est là, la plateforme sur laquelle ces bindings C# sont testées le plus, c'est Mono, pas le .NET propriétaire.

Je viens de regarder un peu là, en fait quand il y a une exception dans un constructeur, elle est remplacée par une System.TypeInitializationException c'est pour ça qu'on voyait rien. En fait l'exception de départ c'est qu'il manque le fichier "svnclient-1.dll" et ce fichier c'est la sortie du projet SubversionSharp\windll\src\svnclient.vcproj qui lui même a besoin des sources de SVN, donc c'est très chiant. Le gars explique ses raisons de faire ça ici.

Sinon il y a un fork qui s'appelle Svn.NET qui propose un build, j'ai pas essayé mais le nombre de dépendances ça fait peur

AprSharp.dll
intl3_svn.dll
libapr.dll
libapriconv.dll
libaprutil.dll
libdb44d.dll
libeay32.dll
Mono.GetOptions.dll
ssleay32.dll
SubversionSharp.dll
svn_client-1.dll

Ah je viens de tester le getting started c'est cool ça marche sauf qu'il faut remplacer SvnWcNotify.Action par SvnWcNotify.Actions

pfou... c'est dingue comment avec un système de solutions/projets qui marche très bien sous Visual Studio, les gens arrivent encore à faire des trucs qui compilent pas avec un simple clic sur un bouton :/

ce que t'as réussi à faire marcher, c'est Svn.NET ? (je peux pas le compiler, j'ai pas installé le compilo c++ pour vs :/)

Ben, ils (ou du moins certaines dépendances) utilisent des systèmes de compilation portables (qui marchent avec Mono aussi, en l'occurrence, ou avec GCC/g++ dans le cas des dépendances C/C++), pas les projets VS propriétaires, c'est pour ça.

Quant aux dépendances, ce n'est pas grand chose:
* APR et APR# (l'auteur explique pourquoi c'est nécessaire)
* OpenSSL (pas étonnant, tu veux faire du SVN par SSL comment sinon? => dépendance de SVN)
* BerkeleyDB (alias "db4", dépendance de SVN)
* Mono.GetOptions (bah, ils visent Mono à la base, donc c'est normal qu'il faille une assembly Mono, soyez contents que ça n'en est qu'une)
* Subversion lui-même (évidemment )
Certaines de ces dépendances contiennent plusieurs DLLs (c'est pour ça que la liste des DLLs est plus longue), mais c'est comme ça.

Bon tant pis, j'ai installé VC++, du coup ça compile, mais quel bordel

(le plus simple reste quand même de prendre telles quelles toutes les dll, les mettre dans un coin, et surtout ne plus jamais y toucher )

merci pour les liens Twindruff

Je sens une certaine phobie du libre et portable dans le ./12.

Bah ce projet est exactement l'illustration du libre pour moi : c'est portable, mais j'en ai pas besoin, par contre du coup c'est une catastrophe à compiler alors que si ça avait été un projet Visual Studio classique, ça aurait compilé en un clic et je n'aurais jamais eu tous ces problèmes

Bah, tout le monde n'utilise pas l'OS du monopole ni le compilateur du monopole.

je connais l'url, pas la peine de la remettre à chaque fois que t'écris le mot "monopole"; et le compilateur du monopole, au moins, il permet de faire des trucs qui évitent de perdre une journée avant de commencer à développer ^^

bon pour revenir dans le sujet, y'a une manip particulière à faire pour que les dll soient prises en compte ? parceque j'ai réduit le projet SVNdotnet au strict minimum et j'ai ajouté une form de test, ça marche, par contre si je recrée mon propre projet et que j'y inclus ArpSharp / SubversionSharp / les dlls, ça me balance quand même une "System.DllNotFoundException" à l'instanciation de SvnClient :/

./10 et ./12 ah tu t'es fait chier, j'ai utilisé le build tout fait de svn.net moi par contre c'est la version debug

./16 ben essaies de catcher l'exception et de regarder le message détaillé, il y a le nom de la dll qui manque normalement dans la propriété message de l'exception. Sinon j'ai juste mis en référence les assemblies .net et mis les autres dll du build dans le répertoire de mon exe c'est bourin mais c'est juste un test

Le gars utilise nant ça explique un peu pourquoi les projets visual studio qu'il a fourni sont hyper mal faits.

c'est bon j'ai trouvé, y'avait un #ifdef WIN32 au début de "Apr.cs", et le nom de la lib n'est pas le même entre Windows et Unix, du coup il cherchait la mauvaise.

ouf, ça marche, j'y touche plus

arg bon enfin ça marche

oué, plus qu'à trouver comment on s'en sert, genre comment on spécifie un login/mdp quand on checkout, vu que "SvnClient" n'a aucun attribut qui a l'air de ressembler à ça ^^

[edit] bon, à défaut de doc, y'a ptet des infos là dedans http://svnexpert.sourceforge.net/

Zephyr (./20) :
oué, plus qu'à trouver comment on s'en sert, genre comment on spécifie un login/mdp quand on checkout, vu que "SvnClient" n'a aucun attribut qui a l'air de ressembler à ça ^^

[edit] bon, à défaut de doc, y'a ptet des infos là dedans http://svnexpert.sourceforge.net/

tiens bah au moins lui il compile bien

yep, nikel ce truc, si j'avais trouvé ça avant ça m'aurait évité de complications ^^

(mais c'est parfait pour comprendre comment marche SvnClient; le coup des mots de passe j'aurais pu chercher un moment à mon avis ^^)

J'vais ptet dire un truc con, mais ça serait pas plus simple d'en récupérer un en ligne de commandes et de l'appeler et parser le résultat ?

si, c'est la solution que j'utilise actuellement, mais bon... :/

C'est une bonne solution en général : modulaire et portable.
Certes tu perds un peu de temps à lancer un processus supplémentaire, mais de toutes façons c'est négligeable au regard du temps consommé par les opérations exécutées par svn.

Beaucoup d'applications unix fonctionnent sur ce modèle, les interfaces graphiques étaient en réalité des frontend aux programmes en ligne de commande. Ainsi, chaque programme se concentre sur son unique tache : le programme qui bosse ne se soucie pas d'interface et d'interaction avec l'utilisateur, et le programme qui fait interface ne se soucie pas des détails techniques.

L'un des exemples "d'école" serait K3B, le nero-like de kde. Il ne sait absolument rien faire, mais combine lame, cdrecord, mkisofs, divers programme d'encodage te décodage pour parvenir à ses fins (les geek peuvent lui demander d'afficher les lignes de commande qu'il génère ).

Et puis, si demain tu veux changer de backend, t'as juste à modifier ton parsing, c'est simple

Personnellement, je trouve que c'est une solution plutôt sale, et utiliser une librairie est plus pratique quand c'est possible. Le gros problème est que tu te retrouves à parser une sortie qui n'est pas forcément faite pour être parsée par un programme, donc ça risque de boguer si le format de la sortie change, si le logiciel est traduit etc. Et pour la portabilité, ça dépend aussi de comment tu le lances, l'exécutable externe. Un truc comme QProcess de Qt 4 est portable, un truc comme CreateProcessW (Win32) ou comme KProcIO de KDE 3 (K3ProcIO dans KDE 4) ne l'est pas.

En général, une librairie avec une bonne interface est beaucoup plus pratique qu'un exécutable externe. Pas besoin de parser, pas besoin d'exécuter, pas besoin de rediriger la sortie etc.