sur svn on pouvait avoir des surprises mais je pense que git et hg essaient d'être moins magiques et génèrent des conflits manuels plus souvent.
2013/9/11 Franck Paul <[email protected]> > Attention au tout auto sur les merges, parfois ça donne des surprises > (genre code déplacé mais conservé et modifié, etc). > > > Le 11 septembre 2013 10:30, Julien Wajsberg <[email protected]> a écrit : > > > 2013/9/11 Kozlika <[email protected]> > > > > > Le 11 septembre 2013 10:21, Julien Wajsberg <[email protected]> a > écrit : > > > > Non mais même sur svn ça marche ça :) > > > > > > > > > Alors... Il y a la thérorie, il y a les manipulateurs experts d'outils > > > et il y a les autres. > > > > > > Moi ce que je constate c'est que quand je fais ce genre de passe, > > > certains s'en tapent (nikrou, toi) et d'autres me maudissent. Tenir > > > compte de tout le monde sur un projet collaboratif c'est aussi éviter > > > le "worksforme". Mais je ne doute pas qu'après nos ateliers du 21 je > > > pourrai faire tout ce que je veux quand je le veux ;-) > > > > > > > Qu'on ne se méprenne pas, c'est super bien que tu préviennes dans ce > genre > > de cas, et c'est une bonne pratique, il faut le faire à chaque fois. > > > > En revanche, on n'est plus à l'ère des outils qui ne savent pas gérer les > > conflits sur un fichier. Certes, quand on édite le même fichier, on peut > > avoir des conflits (et ok, je note qu'on peut faire une session débutant > > là-dessus le 21), mais les outils savent les gérer automatiquement quand > > ils sont pas dans la même partie du fichier. > > -- > > Dev mailing list - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Franck > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
