Re: svn

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 la main, ou pour persister, dans votre .bashrc.