• # Hook

    Posté par  . Évalué à 2.

    Tu pourrais t'en sortir en créant ou en recherchant un hook sur le commit mais l'utilsateur ne sera prévenu qu'au moment du commit qu'il n'avait pas le droit de supprimer un fichier

    Si tu veux un système à la ClearCase qui offre des hooks sur le client et qui permettrait de prévenir l'utilsateur dès qu'il lance la commande "svn del" c.a.d. avant le commit il faudrait locker tous les fichiers par défaut créer un hook pre-unlock et invoquer la commande snv unlock --force avant tout modification de fichier.
    Tu aurais quelques chose d'équivalent à Clearcase. Sous Cleracase tous les fichiers sont en lecture seule. Avec la commande cleratool checkout -unreserved tu extrait un fichier pour modification et cette opération permet de déclencher un hook (trigger préop en jargon CC) sur cette opération. La différence serait que ton hoook se declencherait sur le serveur et pas en local.

    Quoiqu'il en soit ca reste une solution très lourde et je me pose la question sur l'intêret d'un telle demande.
    Il ne faut pas oublier que SVN à la différence de CVS supporte le versionnage des répertoires et que chaque commit crée une nouvelle révision complète de ton projet. Si un utilisateur supprime par erreur, un fichier tu as donc tjs moyen de le restaurer.
    En outre il faut faire un minimum confiance à tes utilisateurs. En général choisir de supprimer avec une commande explicite comme "svn del" signifie que l'on sait ce que l'on veut faire. Bien que cela t'apportes une impression de sécurité, ca risque d'^tre contre-productif. Les developpeurs qui vont passer leur temps à demander des suppressions de répertoires et le compte privilégié va perdre son temps à traiter ces demandes.

    • [^] # Re: Hook

      Posté par  . Évalué à 2.

      Sinon si tu pensais à la mise en oeuvre des ACL. En plus d'Apache ( fichier svn-acl) tu as la rfc3744 (WebDAV) mais je n'ai pas l'impression que ca puisse convenir puisque le privilège se limite à l'ecriture (DAV:Write).Si tu l'appliques au répertoire, ca verrouillera aussi la création de nouveau fichier.
      http://www.ietf.org/rfc/rfc3744.txt

      En tout cas, si tu trouve je suis interessé par ton retour d'expérience.

  • # git

    Posté par  (site web personnel) . Évalué à 2.

    Quand je vois la complexité de mise en oeuvre d'une demande aussi simple, je comprends mieux pourquoi Linus est si méchant envers svn.

    "La première sécurité est la liberté"

    • [^] # Re: git

      Posté par  . Évalué à 2.

      Je ne vois pas ce que git ou n'importe quel DVCS apporterait à l'affaire.
      Avec ce genre d'outil tu fais la suppression dans la branche qui t'es dédiée dans ton archive et l'intégrateur choisra de ne pas l'intégrer dans l'archive centralisée.

      L'utilisateur n'aura pas plus été prévenu qu'il ne devait pas le faire et rien n'empêche de créer une branche par developpeur et une branche d'intégration pour arriver au même résultat dans SVN.

      • [^] # Re: git

        Posté par  (site web personnel) . Évalué à 2.

        Sauf qu'il y a une des 2 solutions super plus chiantes à gérer.

        J'imagine que le but d'une telle demande est qu'un des personnes fassent un code review. C'est exactement le principe des DVCS que chaque personne gère ses vues.

        "La première sécurité est la liberté"

        • [^] # Re: git

          Posté par  . Évalué à 2.

          Avec une code review un simple checkout anonyme suffit.
          Si le code review nécessite de modifier les sources et qu'on a peur de pourrir les sources on crée la branche dédiée on limite l'accès à la branche pour le réviseur et c'est marre.

          Par contre tu m'expliqueras comment fait une équipe d'intégrateurs ou des développeurs pour mettre à jour en concurrence un espace d'intégration avec un DCVS qui est par nature user-centric. Tout le monde n'a pas les compétences d'un dictateur bienveillant. Les outils centralisés permettent les 2 approches au moins.

          • [^] # Re: git

            Posté par  (site web personnel) . Évalué à 2.

            Je travaille avec clearcase, et franchement la gestion croisé des branches perso avec merge dans la branche principal et dans des branches secondaire est un merdier sans nom.

            Par contre tu m'expliqueras comment fait une équipe d'intégrateurs ou des développeurs pour mettre à jour en concurrence un espace d'intégration

            Il n'y a pas de mise à jour en concurrence mais c'est celui qui a besoin d'une "nouveauté" qui va l'inclure dans son arbre. Cela sera le role du responsable de l'intégration du tout. Le mec qui actuellement passe ses journées à merger des modifs pour lancer une régression pour faire une nouvelle release.

            "La première sécurité est la liberté"

            • [^] # Re: git

              Posté par  . Évalué à 2.


              Je travaille avec clearcase, et franchement la gestion croisé des branches perso avec merge dans la branche principal et dans des branches secondaire est un merdier sans nom.

              Tu travailles avec UCM plutôt non ?
              Chaque dev bosse dans sa propre branche et merge sur la branche d'intégration. A part le fait que la branche du développeur est sur le serveur au lieu d'être en local ca ne change rien par rapport à un DVCS. (Hormis le confort dans certains cas j'admet et l'administration )

              Quant à l'outil de merge de Clearcase c'est le plus abouti que je connaisse et l'assistant de merge pour merger des arbo est redoutable.
              Si ya bien un truc qu'on peut pas reprocher à CC c'est bien ca.
              Si tu as des soucis c'est peut-être dû a des pbs d'organisation (conventions de nommage des branches, ... conatcet moi si tu veux un audit gratos;) plutôt qu'à autre chose et tu aurais les même pbs avec un DCVS. Les outils ne pallient pas la gestion de projet.


              Il n'y a pas de mise à jour en concurrence mais c'est celui qui a besoin d'une "nouveauté" qui va l'inclure dans son arbre. Cela sera le rôle du responsable de l'intégration du tout. Le mec qui actuellement passe ses journées à merger des modifs pour lancer une régression pour faire une nouvelle release.

              C'est bien ce que je disais la seule approche possible est user-centric. Avec un CVS centralisé l'autre approche est possible.
              Celui qui as besoin de nouveauté se réaligne par rapport au dernier niveau OK (rebase) mais quelquefois les développeurs sont les plus compétents pour savoir comment intégrer leur modif au tronc commun. Avec CC tout le monde peut faire un deliver et c'est le cas avec SVN aussi (Sauf qu'en plus tu na pas besoin de créer une branche par developpeur si tu traite une seul changement à la fois et que tu l'intègres). CC propose en fait UCM entre autre pour pallier le fait que le commit n'est en fait pas atomique et qu'il est donc imossible de l'associer à un changeset ).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.