Path: ...!weretis.net!feeder8.news.weretis.net!news.imp.ch!news.alphanet.ch!alphanet.ch!.POSTED.localhost!not-for-mail From: Marc SCHAEFER Newsgroups: fr.comp.os.linux.configuration Subject: Re: svn Supersedes: Date: Fri, 4 Feb 2022 13:47:07 -0000 (UTC) Organization: Posted through ALPHANET Message-ID: References: <20220204142754.46887ff7@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 4 Feb 2022 13:47:07 -0000 (UTC) Injection-Info: shakotay.alphanet.ch; posting-host="localhost:127.0.0.1"; logging-data="12996"; mail-complaints-to="usenet@alphanet.ch" User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-18-amd64 (x86_64)) Cancel-Key: sha256:wyoaYp86xueLQzmBBeVJEtiPel9Rcug/rNJztVcAoVQ= Cancel-Lock: sha256:Xu/hNH9UJQwBEQXYEe2WCAa1EJgTzx3IOKCvOtPg8Dc= Bytes: 3735 Lines: 57 Pat Pato wrote: > A quoi servirait donc de changer l'éditeur par défaut: cvs, git, svn et d'autres outils vont lancer l'éditeur texte pour les messages de commit, s'ils ne sont pas précisés par l'option -m (en tous cas pour cvs et git). Si la valeur par défaut ne vous convient pas, il est possible de la changer, soit avec update-alternatives (sous Debian, pour le système, programme sensible-editor), soit avec une variable d'environnement > export SVN_EDITOR=vim Enfin je suppose, j'ai utilisé rcs, cvs et git comme CVS et jamais svn. J'adorais rcs pour sa simplicité (typiquement wiki.alphanet.ch tourne Foswiki en backend rcs pour l'historique du markdown), cvs pour sa compatibilité avec rcs et sa simplicité tout en permettant le travail en groupe. svn m'aurait peut-être été utile si j'avais travaillé avec des personnes sous plateforme Microsoft (conversion des fins de ligne, etc) à l'époque. git est mon choix actuel, même s'il a quelques problèmes par exemple avec les renommages. Sa compatibilité des OS non standards (Microsoft) est vraiment bonne à ce que j'ai pu voir (hormis quelques corruptions parfois), et pour que les symlinks marchent, il faut bricoler apparemment. En effet, cvs et rcs permettaient les renommages sans perdre l'historique (mais en perdant l'historique du renommage lui-même). git fait le contraire: par défaut, sans utiliser des commandes spéciales, on perd l'historique avant le rename, ou alors il faut utiliser des commandes de substitution. Typiquement pour passer mes repositories de cvs à git, j'ai utilisé un script, et pour fusionner ou déplacer sans perdre l'historique (mais en perdant l'historique du déplacement) j'ai utilisé ces fameuses commandes de substitution. Ca marche mais c'est curieux. C'est marrant d'avoir des repositories git qui remontent à l'an 2000 voire avant. Je crois me rappeler que le design de git est en cas de doute, de faire l'inverse des outils précédents, ça se voit :) Avantages de git: chaque work directory est en fait un dépôt entier donc on peut faire des commits locaux; on peut faire du multi-dépôt, les branches sont très naturelles, c'est très, très performant. Inconvénients: le truc des renommages, mais on peut work-aroundiser, et je trouve que l'opération de merge est trop systématique (même si cela ne touche pas les mêmes fichiers), mais il y a peut-être une raison technique derrière. > J'avoue que je ne vois pas non plus en quoi consiste cette opération, > comment je devrais l'exécuter si elle s'avérait nécessaire? A la main, ou pour persister, dans votre .bashrc.