Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

TortoiseSVN + NAS + Subversion = Erreur de commit

[new:27/09/2010]J’ai un NAS, un ReadyNas NV+ 4To, une belle machine qui tourne depuis un mois et demi et dont je suis très satisfait. On peut faire plein de choses. Dont installer un serveur Subversion. Mais si les fichiers à versionner se trouvent eux-même sur le NAS, les commit plantouillent en fin de travail.

C’est une configuration non supportée donc il faut trouver un contournement.

Le ReadyNAS NV+ tourne avec un Linux, un Debian modifié par Netgear. On peut installer une version spéciale de Subversion sur le serveur, c’est vraiment un bon plan (tout le repository est protégé par le X-RAID, du Raid 5 extensible, plus les backup du NAS). Avec WebDav on dispose même d’un accès web au repository, le grand luxe quoi.

Tout fonctionne à la perfection notamment avec TortoiseSVN sur le PC plus AnkhSVN en addin de Visual Studio, un vrai bonheur.

Hélas rien n’est parfait ici bas. Le serveur Samba du NAS + subversion ça marche très bien tant que les working copies se trouvent ailleurs que sur le NAS, sur le PC donc. Mais si jamais on souhaite placer les working copies dans un des shares du NAS, ce qui peut sembler normal après tout (posséder un NAS ça sert à centraliser… s’il faut faire attention à toutes les copies se trouvant sur chaque PC ça devient moins intéressant).

Les commit marchent bien, on ne perd donc rien, mais en fin de commit on obtient une erreur fâcheuse de type Access Denied sur un déplacement / suppression de fichier. Il s’agit des fichiers de Subversion mis à jour en fin de commit. Ils sont marqués readonly par subversion et Samba refuse de supprimer, remplacer ou bouger un fichier de ce type. Il y a un petit problème, connu d’ailleurs, dans cette combinaison de logiciels et cette configuration précise (working copy placée sur le NAS).

La solution

Elle n’est pas vraiment très “propre”, mais en l’absence d’une vraie réponse : la correction du problème dans Samba ou Subversion, il faut bien se contenter d’une astuce.

Elle consiste tout simplement à modifier la configuration de Samba justement et à autoriser le delete des fichiers en readonly dans le share où on souhaite poser des working copies (ça ne sert à rien de le faire dans les autres shares et d’ouvrir des brèches…).

Pour cela :

  • Lancer Putty sur le PC, se connecter au NAS en root avec le password de ce dernier
  • Editer par VI le fichier /etc/frontview/samba/Shares.conf Il se présente comme un fichier INI en gros avec des sections qui sont les noms des shares.
  • Dans le share (ou les shares) où le problème se pose, ajouter “delete readonly = yes” (sans les guillemets et avec les espaces).
  • ZZ (pas dodo, non : sauvegarder les modifs et sortir de VI, c’est du Linux hein, tout en codes bizarres pire que MS DOS 1.0, faut en vouloir en 2010 pour se goinfrer des trucs moyenâgeux de la sorte, je vous le dit ! C’est comme un OS case sensitive dans les noms de fichier, ils veulent vraiment conquérir le monde avec une connerie pareille ?)

Bref, l’affreuse modif étant faite, Samba pourra supprimer les fichiers readonly dans le share modifié. C’est pas très malin mais ça lève le problème des commit de Subversion, et puis le mode readonly des fichiers on ne se repose pas là-dessus pour la sécurité de ses données sinon on est vraiment idiot ou inconscient, voire les deux…

Et ça marche ! Dingue.

Bon commit !

Et Stay Tuned !

Faites des heureux, PARTAGEZ l'article !

Commentaires (4) -

  • Max

    28/09/2010 14:34:10 | Répondre

    Bonjour,
    j'ai le même problème avec un NAS Synology, malheureusement malgré le paramètre delete readonly = yes dans la section [global] de la conf Samba (3.2.8), et après redémarrage du daemon, j'ai toujours ce meme message d'erreur lors du commit.

    A noter que le fichier interne que svn tente de supprimer après le commit n'a pas l'air d'avoir été créé du tout, donc surement pb d'ecriture directement.

    Cela pourrait-il etre causé par un pb d'identité du process svn client sur le NAS ? D'autres idées, des pistes ?

    Max.

  • Olivier

    28/09/2010 19:44:30 | Répondre

    @max: il m'a aussi semblé que parfois l'astuce ne passait pas, et je ne saurais pas dire pourquoi c'est un "coup oui un coup non"...
    Mais si on se réfère à tout ce qu'on peut trouver comme info sur la question, c'est simple : avec suberversion installé sur NAS il ne vaut mieux pas avoir de working copy sur le même NAS Frown Triste mais c'est la conclusion qui s'impose. Subversion ou Samba ont un bug, une incompatibilité, que sais-je, c'est connu, on trouve plein de gens dans ce cas, et, hélas, la combine pour s'en sortir semblent passer chez certains et moyennement chez d'autres...
    C'est bien entendu un problème de droit, quand suberversion bricole ses fichiers, c'est un soft Linux tournant sous Linux et tripotant des fichiers Linux, alors que ces mêmes fichiers via Tortoise ou Ankh sont attaqués par des processus Windows avec les règles windows. C'est très bien fait tout cela mais la gestion des droits est un tel enfer aussi bien sous Windows que sous Linux qu'obtenir une parfaite harmonie entre les deux est certainement un doux rêve. En tout cas pas aussi facilement qu'on aimerait !
    Quand un commit ne passe pas, il faut savoir que c'est uniquement les fichiers .svn qui ne sont pas correctement mis à jour. Il suffit de faire un clic droit sur le dossier considéré et de supprimer tous les marqueures "read only" puis de passer un Tortoise "clean up". Ca remet tout correctement sans aucune perte du commit lui même. Mais subversion recréé derrière les fichiers en read only et il faut faire cette manip à chaque fois donc. Un peu lourdingue...
    J'en suis revenu à es working copies sur les disques locaux. Après tout c'est logique : tout ce qui est versionné est déjà protégé sur le NAS en Raid, en local ce n'est qu'une working copie. On la commit et tout va bien. Quand on a finit de bosser sur un dossier, on peut en faire une copie sur NAS (sans les .svn, avec un export par ex), histoire de ne pas avoir que la version gérée par subversion.
    C'est en tout cas comme ça que je fait maintenant. Il me reste quelques dossiers directement sur le NAS et versionnés. Certains ça passe bien , d'autres il faut la combine de suppression du readonly + cleanup en fin de commit. POur les trucs qui bougent peu c'est parfait et ça évite de gérer trop de copies locales.
    Autre chose à noter : la compilation et l'exécution d'un soft via Visual Studio ou Blend en local est autrement plus rapide que par le NAS malgré tout. On a donc tout intérêt à conserver une logique "working copy locale".
    Ou alors il faudrait être cohérent : un NAS avec le repository et un autre pour les dossiers, je pense que le problème de droit disparaîtrait (mais cela reste à tester ! si un lecteur à deux NAS qu'il se fasse connaître !).

  • txupi

    18/04/2011 16:30:18 | Répondre

    Bonjour à tous,
    Possédant également un ReadyNas NV+, j'aurais aimé savoir comment vous avez fait pour faire fonctionner tortoiseSVN avec ce serveur.
    Je ne touche pas trop en système donc j'ai un peu de mal.
    Après avoir installé apt-get et  SVN, j'ai créé mon repository mais je n'arrive pas à y accéder avec tortoise.
    Auriez vous un "tuto" ou une marche à suivre?
    En vous remerciant.

  • Olivier

    18/04/2011 17:21:11 | Répondre

    @txupi: Ça fait presque un an que j’ai fait la manip et n’étant pas un expert Linux une fois que ça a fonctionné je n’ai plus touché à rien …
    En revanche ce que je sais c’est que je n’ai pas utilisé apt-get ni rien téléchargé de « linuxien ».
    La manip a consisté à télécharger un add-on du NAS pour en autoriser l’accès en mode root, puis a télécharger une version de Subversion spécialement compilée pour le ReadyNAS.
    Ca a été plutôt facile, même si gérer les droits sur le NAS a lui été sportif jusqu’à ce que je comprenne que pour des raisons linuxiennes (que je n’ai pas creusées) il ne fallait pas avoir des dossiers gérer sur le NAS avec un subversion sur le NAS aussi. Donc la méthode de travail est la méthode « normale » en réseau : tout avoir en copie locale sur sa machine et faire des commits vers subrversion qui est sur le NAS. Après quelques bricolages j’ai réussi à faire en sorte qu’on puisse stocker un dossier géré sous subversion dans un autre share du NAS mais parfois ça marche mal et il faut passer un « clean » sur le répertoire.

    Les modules que j’ai installé sur le NAS sont les suivants :

    •  Add-on subversion spécial readynas : readynasfreeware.org/projects/nas-subversion-full
    •  Et l’add-on WebSVN qui permet de browser les projets en mode web : http://www.websvn.info/

    Il semble que les deux réclament l’activation du serveur Apache, ce qui s’est fait tout seul à l’installation d’après mes souvenirs.

    Espérant que cela vous aidera à faire fonctionner subversion sur votre NAS, ce qui est très pratique il faut l’avouer !

Ajouter un commentaire