Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc SCHAEFER
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 :)
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.
Pat Pato <patou@doremifasol.com> 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 :)
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 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 :)
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.
Marc SCHAEFER
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.
Pat Pato <patou@doremifasol.com> 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 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.
Matthieu
Le 04.02.2022 Í 13:47 Marc SCHAEFER a écrit:
Inconvénients: le truc des renommages, mais on peut work-aroundiser,
Il y en a d'autres, des inconvénients... - stockage difficile de gros binaires (oui, on peut, mais de nouveau il faut work-aroundiser) - pas de numéros de révision qui s'incrémentent - tout le monde doit garder l'historique complet de tout le monde ("chaque utilisateur est un serveur") - gestion de droits sélectifs difficile Í implémenter - "commits locaux" qui encouragent Í garder ses changements chez soit, contrairement Í la bonne pratique "commit early, commit often" - ... git est génial pour de la collaboration décentralisée Í très grande échelle. Normal, puisque c'est précisément ce pour quoi il a été créé. Mais c'est un besoin de niche... Or aujourd'hui les gens l'utilisent pour tout et n'importe quoi. Effet de mode, je suppose. Dommage, car svn est largement plus simple et efficace pour la vaste majorité des projets de développement "normaux". Matthieu
Le 04.02.2022 Í 13:47 Marc SCHAEFER a écrit:
Inconvénients: le truc des renommages, mais on peut work-aroundiser,
Il y en a d'autres, des inconvénients...
- stockage difficile de gros binaires (oui, on peut, mais de nouveau il
faut work-aroundiser)
- pas de numéros de révision qui s'incrémentent
- tout le monde doit garder l'historique complet de tout le monde
("chaque utilisateur est un serveur")
- gestion de droits sélectifs difficile Í implémenter
- "commits locaux" qui encouragent Í garder ses changements chez
soit, contrairement Í la bonne pratique "commit early, commit often"
- ...
git est génial pour de la collaboration décentralisée Í très grande
échelle. Normal, puisque c'est précisément ce pour quoi il a été créé.
Mais c'est un besoin de niche... Or aujourd'hui les gens l'utilisent
pour tout et n'importe quoi. Effet de mode, je suppose. Dommage, car
svn est largement plus simple et efficace pour la vaste majorité des
projets de développement "normaux".
Inconvénients: le truc des renommages, mais on peut work-aroundiser,
Il y en a d'autres, des inconvénients... - stockage difficile de gros binaires (oui, on peut, mais de nouveau il faut work-aroundiser) - pas de numéros de révision qui s'incrémentent - tout le monde doit garder l'historique complet de tout le monde ("chaque utilisateur est un serveur") - gestion de droits sélectifs difficile Í implémenter - "commits locaux" qui encouragent Í garder ses changements chez soit, contrairement Í la bonne pratique "commit early, commit often" - ... git est génial pour de la collaboration décentralisée Í très grande échelle. Normal, puisque c'est précisément ce pour quoi il a été créé. Mais c'est un besoin de niche... Or aujourd'hui les gens l'utilisent pour tout et n'importe quoi. Effet de mode, je suppose. Dommage, car svn est largement plus simple et efficace pour la vaste majorité des projets de développement "normaux". Matthieu
Marc SCHAEFER
Matthieu wrote:
- pas de numéros de révision qui s'incrémentent
c'est juste, et j'ai dÍ» renoncer aussi au $Id$ (ça doit être possible des les activer, mais j'ai fait autrement).
- tout le monde doit garder l'historique complet de tout le monde ("chaque utilisateur est un serveur")
Juste.
- "commits locaux" qui encouragent Í garder ses changements chez soit, contrairement Í la bonne pratique "commit early, commit often"
Oui, il ne faut pas oublier les push.
Matthieu <matthieu@x.localhost> wrote:
- pas de numéros de révision qui s'incrémentent
c'est juste, et j'ai dÍ» renoncer aussi au $Id$ (ça doit être possible
des les activer, mais j'ai fait autrement).
- tout le monde doit garder l'historique complet de tout le monde
("chaque utilisateur est un serveur")
Juste.
- "commits locaux" qui encouragent Í garder ses changements chez
soit, contrairement Í la bonne pratique "commit early, commit often"
Le Fri, 4 Feb 2022 15:18:19 -0000 (UTC), Marc SCHAEFER a écrit :
Matthieu wrote:
- pas de numéros de révision qui s'incrémentent
c'est juste, et j'ai dÍ» renoncer aussi au $Id$ (ça doit être possible des les activer, mais j'ai fait autrement).
- tout le monde doit garder l'historique complet de tout le monde ("chaque utilisateur est un serveur")
Juste.
- "commits locaux" qui encouragent Í garder ses changements chez soit, contrairement Í la bonne pratique "commit early, commit often"
Oui, il ne faut pas oublier les push.
Je vous rmercie. Patrick
ptilou
Le vendredi 4 février 2022 Í 14:27:57 UTC+1, Pat Pato a écrit :
Bonjour, A quoi servirait donc de changer l'éditeur par défaut: export SVN_EDITOR=vim 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?
Un peut de sérieux , ed, emacs, voilÍ de vrai éditeur …. A broder dans un endroit forwarded par certificat bidonné … — Ptilou
Le vendredi 4 février 2022 Í 14:27:57 UTC+1, Pat Pato a écrit :
Bonjour,
A quoi servirait donc de changer l'éditeur par défaut:
export SVN_EDITOR=vim
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?
Un peut de sérieux , ed, emacs, voilÍ de vrai éditeur ….
A broder dans un endroit forwarded par certificat bidonné …
Le vendredi 4 février 2022 Í 14:27:57 UTC+1, Pat Pato a écrit :
Bonjour, A quoi servirait donc de changer l'éditeur par défaut: export SVN_EDITOR=vim 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?
Un peut de sérieux , ed, emacs, voilÍ de vrai éditeur …. A broder dans un endroit forwarded par certificat bidonné … — Ptilou
