Question

J'utilise des systèmes de contrôle de version distribués depuis quelques années, mais maintenant je vais devoir utiliser CVS. Le processus que je veux est quelque chose comme:

  1. Chaque bogue / fonctionnalité reçoit un ticket dans un système de billetterie
  2. Un développeur est affecté à un bug / fonctionnalité (si nécessaire un ticket sera divisé en billets plus petits pour que le développeur fasse un ticket la relation est un à un)
  3. Le développeur apporte des modifications et les associe au ticket
  4. À des moments réguliers, un ensemble de les billets sont choisis pour une sortie candidat Le candidat à la libération être testé
  5. Une version est créée à l'aide d'un sous-ensemble de les billets du candidat
  6. et le cycle recommence

Mon plan actuel et naïf est de

  1. placez chaque ticket dans sa propre branche du tronc
  2. créer une branche pour chaque release candidate
  3. fusionner les branches du ticket dans la release candidate
  4. lorsqu'une version candidate est considérée comme suffisamment bonne, fusionnez-la dans le tronc

J'ai oublié tout ce que je savais sur CVS, mais j'ai le pressentiment qui me dit que ce sera une erreur. Quelles performances ou autres types de problèmes vais-je rencontrer? Existe-t-il un meilleur moyen de créer de manière sélective des builds basés sur un sous-ensemble du travail effectué pendant une période donnée?

Était-ce utile?

La solution

Vous pouvez utiliser localement un système de contrôle de version distribué et publier sur CVS lorsqu'une fonctionnalité est prête à être publiée.

Voir cette question: Comment exporter l'historique des révisions de mercurial ou git vers des cvs?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top