Aïe... Non, ce ne sont pas les même notions (mais venant d'un utilisateur de Clearcase ça ne m'étonne pas )
Faux, Eclipse gère des versions de fichiers, pas de sources. Une version de sources est l'état de l'ensemble de tes fichiers (pour SVN, Git, Mercurial, Baraar...). Comment peut tu restaurer l'état de tes sources à la modification n donnée d'un fichier avec l'outil d'Eclipse ?
Oui et non. Pour cela, il y a les tags et les liens vers les versions spécifiques dans les outils de suivi de tickets.Le but d'un outil de version logiciel, c'est de sauvegarder les réelles nouvelles versions : correction d'un bug, évolution, nouvelle fonction, etc.
Au contraire, un exemple de théorie : http://martinfowler.com/bliki/FeatureBranch.htmlCe principe ne peut pas s'appliquer dans un projet avec 25 développeurs sur une MC (maintenance corrective) + 3 projets d'évolution successifs conséquents en relation avec d'autres évolutions de logiciels connectés en //
Pour le reste, tu confond version de sources (qui trouve sa place dans un gestionnaire de sources) et version logicielle (qui est le tag d'une livraison). Sans ajouter la caricature du projet OpenSource ( = non structuré). Sans prôner la multiplication des versions à outrance, versionner souvent permet d'isoler les modification. Si tu dois versionner uniquement l'ensemble du travail fini, tu a plus de chance d'introduire, d'amplifier, et de rendre difficilement identifiable un "bug" (je veux rester générique).
On ne va pas se les comparer, mais je rajouterai que beaucoup de développeurs n'y comprennent rien tout court. Pas la peine d'être au début ou plus loin. Pour la plupart, gérer une version consiste à exécuter un update/commit en priant qu'il n'y ai pas de merge. Le sens derrière...La gestion de conf, j'en bouffe depuis 5+ ans maintenant et je réalise maintenant comme un développeur n'y connait rien au début ...
Partager