Appel à contribution pour la traduction du livre « Gestion de versions avec Subversion »

Posté par  . Édité par Davy Defaud, Benoît Sibaud et ZeroHeure. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
22
4
oct.
2016
Gestion de versions

Vous avez envie de collaborer à un projet libre, mais vous ne savez pas programmer. Vous maîtrisez l’anglais et vous aimez quand la documentation technique est bien rédigée. Vous voulez approfondir les concepts de gestion de versions et comprendre pourquoi votre logiciel préféré est le meilleur (qu’il s’agisse de Subversion ou d’un autre avec un modèle différent). Si vous vous reconnaissez dans au moins une de ces descriptions, vous pouvez participer !

Subversion continue d’évoluer et la documentation technique qui l’accompagne aussi. Le livre Gestion de versions avec Subversion détaille, non seulement l’ensemble des commandes disponibles, mais fournit aussi des exemples concrets d’utilisation et approfondit les concepts de ces logiciels qui sont au cœur de tout logiciel libre. La version PDF « pèse » environ 500 pages. Autant dire que le travail de traduction ne manque pas.

Ainsi, la version française actuelle du livre Gestion de versions avec Subversion correspond à Subversion 1.5. Afin de recoller à la version anglaise, nous cherchons des volontaires pour poursuivre la traduction pour la version 1.8. Il s’agit donc de :

  • porter la version française 1.5 vers la 1.8 ;
  • traduire les nouveautés depuis la version 1.5 ;
  • faire des lectures croisées pour tout ce qui a déjà été traduit.

Comment participer :

  • pour de petites contribution : soumettez vos améliorations et traductions dans la partie Gestion des tickets de SourceForge ;
  • si vous avez plus d’ambition : créez un compte sur sourceforge.net et demandez les droits de propagation sur le projet.

Au plaisir de vous lire bientôt !

Aller plus loin

  • # command not found: svn

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

    Z'auriez pas un repo git?

  • # svn, git et... mercurial

    Posté par  . Évalué à 10.

    Au fait, qui utilise autre chose que "origin" sur un dépôt git distant?
    Rien que pour ça, il faudrait remplacer git par mercurial.

    • [^] # Re: svn, git et... mercurial

      Posté par  . Évalué à 5.

      Quand je veux corriger un bug/développer une feature pour un projet hébergé sur Github, j'ai toujours 2 dépôts git distants : origin et windu. Le premier pointe vers le dépôt officiel du projet que j'ai forké pour partir de la dernière version, l'autre désigne mon dépôt public personnel.
      Je développe en local, je pousse vers mon dépôt public (windu), puis je fais pull-request vers origin.
      (mais j'imagine que je ne suis pas le seul à faire ainsi)

      • [^] # Re: svn, git et... mercurial

        Posté par  . Évalué à 2.

        Classiquement on utilise "origin" et "upstream".

        Mais on peut très bien décider unilateralement de les appeler "myfork" et "original" par exemple.

        Le tips du jour pour maintenir une pull request le temps qu'il soit intégré: tracker l'upstream (git branch --set-upstream-to=upstream/master my_pullrequest_branch) au lieu de votre origin pour que git pull --rebase vous rebase automatiquement sur la derniere version du code d'upstream. Pour pousser: git push origin.

        Quelle perte de temps SVN, quand même…

    • [^] # Re: svn, git et... mercurial

      Posté par  . Évalué à 7. Dernière modification le 04 octobre 2016 à 18:25.

      Je fais comme windu, et en plus j'ai souvent 2 dépôts de publication, par exemple origin sur gitlab et github sur github.

      Mais je salue la qualité du troll: au lieu de répondre "svn c'est mort passez à git" comme tout le monde, tu réponds par un troll git/hg ignorant carrément le sujet has been de la dépêche. C'est beau !

      J'ai plussé et j'appelle à plusser ce troll de qualité pour qu'il reste positif !

      • [^] # Re: svn, git et... mercurial

        Posté par  . Évalué à -1. Dernière modification le 04 octobre 2016 à 21:37.

        Ha, merci d'avoir perçu mon second degré!

        Je suis condamné aux notes négatives.
        Je ne parle même pas de stackoverflow où je suis partout à 0, et finalement, je n'ai plus le droit de poster car jugé trop inutile! ;-)

        • [^] # Re: svn, git et... mercurial

          Posté par  . Évalué à 1.

          En même temps si tu postes la même chose sur stack overflow qu'ici, faut pas t'étonner… ce sont des gens sérieux qui n'apprécient que les contributions constructives ! reste avec nous plutôt ! Regarde ici, rien qu'au titre de la dépêche tu sais que les trolls seront accueillis et nourris.

    • [^] # Re: svn, git et... mercurial

      Posté par  . Évalué à 0.

      Tout contributeur de Github je dirais

    • [^] # Re: svn, git et... mercurial

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

      J'ai trois ou quatre dépôts git distants, en fonction du contenu et des branches trackées. security par ex est un dépôt qui contient les patches de sécurité en préparation d'une release, puis les dépôts personnels des autres devs, sur lesquels je peux regarder les branches de développement (qui ne se font pas sur master pour les fonctions non triviales).

      Si tu fais un minimum de code review (qui n'en fait pas ?) avant de pusher sur master, les branches/dépôts personnels sont un must.

  • # Pourquoi Source forge ?

    Posté par  . Évalué à 6.

    Après les problèmes de The gimp et d’autre avec sourceforge, je n’y mets plus les pieds. Pourquoi continuer sur sourceforge ?

    Sans rentrer dans les Troll du dessus, n’y a t’il aucune autre forge qui propose du SVN pour les projets libres ?

    • [^] # Re: Pourquoi Source forge ?

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

      n’y a t’il aucune autre forge qui propose du SVN pour les projets libres ?

    • [^] # Re: Pourquoi Source forge ?

      Posté par  . Évalué à 2.

      La migration sur SourceForge fait suite à la fermeture du service Google Code. Les problèmes de publicités intempestives, malwares ou autres restrictions n'ont pas fait l'objet de remarques des contributeurs et donc le "choix" de SourceForge s'est fait de manière très pragmatique : une plateforme libre, offrant les services d'hébergement de code avec Subversion (parce que l'on peut considérer que les contributeurs au livre maîtrisent Subversion), de suivi d'incidents, wiki. Le service semble convenir jusqu'à maintenant. Pour plus d'informations :
      discussion sur la mailing list du livre

    • [^] # Re: Pourquoi Source forge ?

      Posté par  . Évalué à 0.

      Perso je trouve ça assez cohérent: subversion, sourceforge, icq, windows 98se, linux 2.4: la fin glorieuse du 2ème millénaire.

      Bill Clinton, Yasser Arafat, Jacques Chirac, Gerhard Schröder, John Major, Jean-Paul II.

      Titanic, Forest Gump, Jurassic Park, Independence Day, La Menace Fantôme.

      Wolfenstein 3D.

Suivre le flux des commentaires

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