Discussion :

[Orocher31]

Bonjour,

Je travaille sur un projet qui est actuellement développer sous CVS. Je suis en train de le passer sous SVN, hors la gestion des tags et des branches est différente.
Ce projet est réalisé pour deux versions logicielles très similaire (produit1 et produit2): actuellement sous CVS mon projet est développé à 95% sur le tronc et quelques fichiers (5%) sont développé par branche spécifique au produit à développer: branche/produit1 et branche/produit2

Si je ne me trompe pas, cette gestion n'est pas faisable sous SVN puisque tous les fichiers en cours de développement doivent faire parti du même dossier (tronc principal ou dans une branche).

Savez-vous comment je peux organiser mon développement SVN sachant le cycle de développement est le suivant:
produit1 v1: développement sur le tronc et sur la branche/produit1 pour certains fichiers. En fin de dev, utilisation du tag tags_produit1_v1
produit2 v1: part de la dernière version de produit1 v1 mais récupère les quelques fichiers de branche/produit2. En fin de dev, utilisation de tags_produit2_v1
produit1 v2: part de la dernière version de produit2 v1 mais récupère les quelques fichiers de branche/produit1. etc...

Dois-je travailler sur le tronc? Dois-je travailler sur des branches? Comment je peux gérer les quelques fichiers spécifiques aux produit 1 et 2?

J'espère que vous pourrez m'aider car là j'ai un peu de mal.

NB: Je n'ai jamais développé sous SVN, merci de votre indulgence.

[Marco46]

Une question en passant, pourquoi passer d'un SCM ultra obsolète à un SCM obsolète ? Pourquoi ne pas passer de CVS à git directement ?

C'est un peu comme si t'avais un vieux projet php3 tout moisi à réécrire et que tu choisissais struts comme techno c'est vraiment très curieux.

[Orocher31]

Ce n'est pas vraiment MON projet et je suis contraint d'utiliser SVN, je suis même contraint d'utiliser une version spécifique de SVN (1.8.14) afin de rester compatible avec d'autres projets qui sont déjà sous SVN 1.8.14.

Pour les fichiers spécifiques aux produit1 ou produit2, après un checkout du tronc j'espérais faire pour chaque fichier un svn switch des fichiers en question pour pointer vers les repo/branches/produit1/fichierX ou repo/branches/produit2.fichierX. hors si je ne me trompe pas, le svn switch fonctionne sur tout un dossier et pas sur un fichier en particulier. Malheureusement, ces fichiers spécifiques doivent "côtoyer" les fichiers "trunk".

Une autre solution?

[Orocher31]

Finalement je me suis trompé sur la commande svn switch. Elle peut être exécutée sur un fichier unique et pas uniquement sur un dossier. Du coup je pense que nous allons procéder ainsi:
Checkout du tronc et pour les fichiers spécifiques réaliser avant le démarrage du développement un svn switch vers les branches du produit en cours de développement.

Vous voyez un problème à cette méthode?

[sekaijin]

Autre solution

parent/commun/branches
parent/commun/tags
parent/commun/trunk

parent/projet1/branches
parent/projet1/tags
parent/projet1/trunk

parent/projet2/branches
parent/projet2/tags
parent/projet2/trunk

la raison est simple une branche est une divergence du trunk destinée a devenir le futur trunk, être mergé avec le trunk, être abandonnée

en procédant ainsi tu as donc trois projets le "lot commun" et les projets 1 et 2
chacun ayant son trunk il peuvent être releasé indépendamment (tags) si une évolution demande temporairement de s'écarter du trunk tu peux créer une branche.

c'est une mauvais idée que de descendre le source de plusieurs projets dans un même dossier.
il est beaucoup plus efficace de faire du commun un lib un jar ou un livrable quelconque et de faire dépendre les autres projets de cette lib ce jar ce livrable.
un simple make ou maven ou tout autre outil te permets de compiler (assembler) ton projet final sans dépendre du code source d'un autre mais en dépendant du livrable directement.


@Marco46 Quant à dire que SVN est obsolète il faudrait sortir de son trou avant de dire des c@nnr#es. GIT ne réponds pas à tous les besoins. il est des contexte ou ça décentralisation est un handicap. Les deux sont de bon outils dont les domaine d'usage se recouvrent mais ne sont pas totalement les mêmes.

A+JYT

[Marco46]

@Marco46 Quant à dire que SVN est obsolète il faudrait sortir de son trou avant de dire des c@nnr#es.

C'est lent c'est lourd c'est tellement galère à utiliser que ça affecte la productivité d'une équipe.

C'est totalement inadapté à l'usage dans un pipeline CI/CD, bref c'est obsolète.

GIT ne réponds pas à tous les besoins. il est des contexte ou ça décentralisation est un handicap. Les deux sont de bon outils dont les domaine d'usage se recouvrent mais ne sont pas totalement les mêmes.

Je veux bien que tu me cites un cas d'usage couvert par SVN et pas par git.

Je ne vois pas non plus en quoi le caractère décentralisé peut être un handicap. La décentralisation est structurelle, pas du tout obligatoire dans le workflow. On peut faire un workflow centralisé à la SVN avec git, l'inverse n'est pas vrai. Qui peut le plus peut le moins.