Ne t'inquiète pas, maintenant que le backend FSFS est stabilisé et que le support du vérouillage est complet (introduit dans svn 1.2), le "merge tracking" est le prochain changement majeur (dans la catégorisation de mon article, ca serait dans la catégorie "über-changements", au dessus de "ameliorations majeures" ;-) prévu pour l'implémentation. Comme dirait l'un des fondateurs du projet "C'est la grosse montagne à l'horizon. Et on est sur le chemin qui y va."
Là encore, pour ceux qui trouvent que c'est lent, on est pas immobiles. Déjà, Collabnet organise d'ici quelques jours une réunion de ses gros clients, pour leur demander ce que eux, en tant que développeurs, entendent par "Gestion des merges" (on dirait peut-être pas, mais on peut implémenter une immense variété de comportements derrière ce nom vague, avec des dizaines d'UI possibles par implémentation). Une fois que nos développeurs de Collabnet (les seuls payés à plein temps pour subversion) ont le feedback des clients, la question sera posée aux utilisateurs de Subversion en général. Après, l'ensemble des résultats sera digéré, une spécification sera pondue, et l'implémentation démarera.
Juste une petite note concernant la procédure : la question est d'abord posée aux clients de Collabnet parce que nous pensons que leurs ingénieurs et chefs de projet sont à même de nous dire précisément et avec un minimum d'ambiguité ce qu'ils veulent, et que d'avoir quelques définitions claires pourrait aider le "grand public" libre à donner des réponses utiles, plutot que des tautologies du type "on veut un suivi des merges!". Ce n'est absolument pas pour favoriser les clients de Collabnet, et je peux vous assurer que les développeurs de Subversion non-employés par collabnet, une majorité dont je fais partie ne se laisseront pas faire (même s'il n'y a jamais eu besoin de se battre - Collabnet à toujours oeuvré dans le respect complet du "code moral" des projets libre).
Donc voilà, c'est en marche, mais je ne cache pas que cela prendra du temps. Et oui, je suis au courant que nombre de systèmes de contrôle de révision implémentent déjà quelque chose, mais nous préférons bien comprendre le problème avant d'implémenter une solution qui ne fait que la moitié de ce qu'on attend d'elle ;-) Mais réalistiquement, je ne pense pas qu'il faille s'y attendre avant subversion 1.6 au plus tôt (estimation powered by pifomètre, désolé). En attendant, l'utilisation de svnmerge et svk est recommandée pour la gestion des merges, ce sont de bons logiciels (et on se privera pas de leur piquer des idées le moment venu ;-)
[^] # Re: Et un vrai systeme de merge ?
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 10.
Là encore, pour ceux qui trouvent que c'est lent, on est pas immobiles. Déjà, Collabnet organise d'ici quelques jours une réunion de ses gros clients, pour leur demander ce que eux, en tant que développeurs, entendent par "Gestion des merges" (on dirait peut-être pas, mais on peut implémenter une immense variété de comportements derrière ce nom vague, avec des dizaines d'UI possibles par implémentation). Une fois que nos développeurs de Collabnet (les seuls payés à plein temps pour subversion) ont le feedback des clients, la question sera posée aux utilisateurs de Subversion en général. Après, l'ensemble des résultats sera digéré, une spécification sera pondue, et l'implémentation démarera.
Juste une petite note concernant la procédure : la question est d'abord posée aux clients de Collabnet parce que nous pensons que leurs ingénieurs et chefs de projet sont à même de nous dire précisément et avec un minimum d'ambiguité ce qu'ils veulent, et que d'avoir quelques définitions claires pourrait aider le "grand public" libre à donner des réponses utiles, plutot que des tautologies du type "on veut un suivi des merges!". Ce n'est absolument pas pour favoriser les clients de Collabnet, et je peux vous assurer que les développeurs de Subversion non-employés par collabnet, une majorité dont je fais partie ne se laisseront pas faire (même s'il n'y a jamais eu besoin de se battre - Collabnet à toujours oeuvré dans le respect complet du "code moral" des projets libre).
Donc voilà, c'est en marche, mais je ne cache pas que cela prendra du temps. Et oui, je suis au courant que nombre de systèmes de contrôle de révision implémentent déjà quelque chose, mais nous préférons bien comprendre le problème avant d'implémenter une solution qui ne fait que la moitié de ce qu'on attend d'elle ;-) Mais réalistiquement, je ne pense pas qu'il faille s'y attendre avant subversion 1.6 au plus tôt (estimation powered by pifomètre, désolé). En attendant, l'utilisation de svnmerge et svk est recommandée pour la gestion des merges, ce sont de bons logiciels (et on se privera pas de leur piquer des idées le moment venu ;-)