Je travaille sur un projet, qui peut contenir plusieurs versions à plusieurs clients. C'est à dire. 2.65 - version pour le client 1, et 2.67 - version pour le client 2; En règle générale, les différences entre 2,65 et 2,67 sont vraiment minimes - et pour cette raison, il n'est pas nécessaire dans plusieurs branches pour chaque client. Tout ce dont j'ai besoin - corriger la version dans l'historique de travail et, si besoin est, vérifier la version sélectionnée (c'est-à-dire la version 2.65 lorsque la copie de travail est 3.4 - et ajouter quelques modifications pour le client correspondant). J'utilise VisualSVN sur le serveur et TortoiseSVN dans le client. thx)Comment réparer la version du projet dans l'historique SVN?
Répondre
Quel est le problème avec l'utilisation d'une branche pour chaque client, appliquer les modifications nécessaires à chaque branche, puis créer une nouvelle étiquette pour chaque branche?
Exemple:
branche Actuellement client1 a l'étiquette '2,65' et la branche client2 a la balise '2,67'.
Maintenant, vous faites quelques corrections sur le tronc et vous voulez les renvoyer à la branche client1 seulement puisque client2 n'a pas la fonctionnalité où le correctif a été appliqué.
Fusionner les modifications du tronc à la branche client1, de créer un nouveau tag «tout» et de donner cette nouvelle version étiquetée au client.
BTW: TortoiseSVN a une fonctionnalité intégrée Merge que je n'ai jamais travaillé (peut-être ne pas le comprendre). Utiliser Git dans un autre projet m'a montré qu'une fusion intelligente (automatique) pouvait vraiment fonctionner ...
Vous décrivez l'un des cas d'utilisation prototypiques pour les branches. Sérieusement.
Cependant, je suppose que vous supprimez des branches car le portage des modifications entre les branches est une tâche difficile et fastidieuse. C'est lent et vous devez résoudre les conflits difficiles à comprendre. Eh bien, ce n'est pas une limitation des branches: c'est une limitation de Subversion. Apparemment, Subversion ne stocke pas assez d'informations sur vos modifications, ce qui rend la fusion difficile.
D'autres systèmes de contrôle de version modernes sont mieux gérés que Subversion: git, mercurial, bazaar ... Vous pourriez envisager un switch. Quoi qu'il en soit, vous pouvez gérer les branches parallèles même dans Subversion. Jetez un coup d'œil à la section "Branching and Merging" dans le livre "Version Control with Subversion". TortoiseSVN peut être très utile car lorsque vous tentez d'effectuer une fusion, elle grise les révisions qui ont déjà été portées.
Les fusions ne sont pas fonctionnelles sauf si le serveur est 1.5 ou supérieur, c'est peut-être votre problème avec TortoiseSVN: -? –
Merci, dans le résultat je considère les branches comme résolues et, à l'avenir, passer à Mercurial mes projets) – Jamon
@Jamon: Changer d'outil parce que vous ne comprenez pas comment un outil peut fonctionner pour vous ne conduit pas toujours à une meilleure solution. Vous choisissez Subversion pour une raison quelconque. Passez du temps avec elle et explorez divers modèles de branchement. CollabNet a un excellent article sur divers modèles de branchement qui peuvent répondre à vos besoins: http://blogs.open.collab.net/svn/2007/11/branching-strat.html – jgifford25