2009-06-15 5 views
0

Notre société a récemment commencé à créer des succursales CVS pour marquer chaque version. Auparavant, nous utilisions des balises, et si nous corrigions quelque chose pendant la période de test qui devait sortir avec la version, nous avons simplement déplacé la balise vers l'avant. Cela fonctionne bien jusqu'à ce que deux modifications soient apportées au même fichier: une qui devrait être libérée et l'autre qui ne devrait pas l'être. Maintenant, nous devons appliquer le même changement à la fois à la tête et à la branche de libération. J'utilise le plugin CVS d'Eclipse pour interagir avec CVS. Lorsque je regarde l'historique d'un fichier, je vois un tag i20090529Release dans la section Tags (dans ce cas sur la révision 1.30 du fichier), et quand je "Show Tag Viewer" dans la vue Historique, l'icône indique qu'il s'agit d'une branche tag, par opposition à une balise Version. Quand je regarde les révisions qui ont été validées depuis la branche, je vois que la prochaine révision faite à la tête devient la version 1.31, et la prochaine révision apportée à la branche devient la version 1.30.2.1. Ma question est, pourquoi la balise i20090529Release reste avec la version 1.30 du fichier, qui n'est pas la révision la plus récente sur la branche i20090529? Est-ce vraiment une «marque» de bonne foi, ou s'agit-il plutôt d'une idée conceptuelle selon laquelle la succursale a commencé à bifurquer à ce moment-là? Je remarque que je ne peux pas appliquer cette balise à une autre révision du fichier. Pourquoi apparaît-il dans la colonne Balises?Pourquoi l'étiquette de branchement dans CVS n'évolue-t-elle pas?

Merci d'avance pour toute précision que vous pouvez fournir.

+0

Sidenote: vous feriez probablement mieux d'abandonner CVS si à tout est possible pour Git (qui a une notion très claire de branches), ou au moins Subversion (qui utilise une copie bon marché pour les branches, ce n'est pas le meilleur modèle, mais mieux que CVS). –

+0

Point pris. Pour nos nouveaux projets, nous avons commencé à utiliser SVN, mais nous devons encore migrer les anciens. Comment le plugin Eclipse supporte-t-il Git par rapport à SVN? – StriplingWarrior

Répondre

2

C'est l'idée que la succursale a commencé à bifurquer à ce moment-là.

Une branche est un ensemble de versions qui relient le tronc principal à un moment donné et maintiennent leur propre développement indépendant (qui peut bien entendu être étroitement coordonné). Ce n'est pas un ensemble de modifications qui seront automatiquement appliquées aux versions ultérieures. Ce n'est pas une étiquette au sens habituel: si vous extrayez en fonction d'une étiquette, vous obtiendrez un instantané de l'arbre source au moment où l'étiquette a été faite, tandis que les résultats de la vérification selon une branche varie au fil du temps, car les changements sont apportés à la succursale. C'est semblable à une étiquette, et fonctionne de la même manière; CVS utilise l'ancien format de fichier RCS et utilise des balises RCS à la fois pour les branches et les balises CVS.

Il existe plusieurs bonnes références pour CVS. Lisez sur les étiquettes et les branches.

+0

Je vais marquer la bonne réponse parce que vous avez répondu à ma question principale: C'est l'idée que la succursale a commencé à bifurquer à ce moment-là. J'ai lu plusieurs références sur CVS, en particulier les parties sur les tags et les branches. Ce que je n'ai pas trouvé d'information sur était pourquoi cette étiquette est apparue sur la révision originale, même après que j'avais commis de nouveaux changements à la branche. – StriplingWarrior

+0

CVS a démarré sous la forme d'un ensemble de scripts sur l'ancien RCS et a conservé le format de fichier RCS. RCS n'a pas (ou du moins n'a pas) le même concept de branche, donc les balises RCS ont été utilisées à la fois comme balises régulières et comme marqueurs de branches. La balise RCS 1.12.0.2 est le début de la branche 1.12.2, et les balises comme 1.12.2.3 sont des versions le long de cette branche. Il y a beaucoup de petites bizarreries comme ça, ce qui est l'une des raisons pour lesquelles beaucoup de gens sont passés à Subversion. –

0

Les balises normales sont définies pour une révision de fichier spécifique et ne bougeront jamais. S'il est marqué 1.30 il dira 1.30 jusqu'à ce qu'il soit changé manuellement.

Les étiquettes de branches sont stockées dans une révision de branche, si vous branchez un fichier avec la révision 1.30, la première branche sera 1.30.2 (ou le prochain nombre pair libre). Le premier fichier validé dans cette branche obtiendra 1.30.2.1, le prochain commit 1.30.2.2 etc. (voir les détails dans le commentaire d'Oliver Giesen)

La sortie de ce fichier de cette branche (1.30.2) récupérera toujours la dernière révision de fichier dans cette branche (1.30.2.x).

On peut aussi faire des branches dans des branches .. alors révisions seraient Endup comme 1.30.2.2.2 (première branche de la révision du fichier 1.30.2.2) révisions cvs sont <branchrevision>. <filerevison> [. <branchrevision>. <filerevison>] [. <branchrevision>. <filerevison>] ... et ainsi de suite. La première révision de branche est toujours 1 (afaik).

edit: corrigé l'erreur numéro même signalé par Oliver Giesen

+1

Votre description de la façon dont les numéros de révision sont formés n'est pas tout à fait correcte. La seule façon d'obtenir un numéro de branche est en utilisant la commande Importer. Si vous créez une branche vous-même, le numéro de la branche sera toujours un nombre pair qui sera égal au numéro de la branche la plus élevée existant sur un fichier dans le même répertoire. –

+0

... ou 2 s'il s'agit de la première branche créée dans ce répertoire. –

1

Il ne bouge pas probablement parce que vous ne l'utilisez pas - en fonction de votre description, vous vous engagez toujours toutes les révisions à la tête .

Pour utiliser une branche, vous devez d'abord marquer tous les fichiers avec l'étiquette de branche (cet exemple du manuel CVS):

cvs tag -b rel-1-0-patches 

En même temps, je recommande fortement une étiquette de cliché que vous ne jamais déplacer ou mettre à jour, de sorte que vous pouvez toujours reconstruire le code à ce moment:

cvs tag rel-1-0 

pour utiliser la branche, vous devez vérifier la branche dans votre répertoire de travail:

cvs co -r rel-1-0-patches example 

Ensuite, lorsque vous validez des modifications sur la branche, la balise de branche est appliquée à la modification. Ce que vous ne verrez pas, c'est un changement sur HEAD. Pour ce faire, vous devrez fusionner les changements de branche en HEAD, et c'est un peu trop complexe pour mettre dans une réponse SO, alors allez aux docs: http://ximbiot.com/cvs/manual/cvs-1.11.23/cvs_5.html#SEC54

+0

Cela ne correspond pas vraiment à ce que je vois. Je dois mentionner à nouveau, j'utilise le gestionnaire CVS d'Eclipse. J'utilise "Passer à une autre branche ou version" pour vérifier la branche, et quand je m'engage, je vois que le numéro de révision a changé de format de la même manière que Joakim. Cependant, dans Eclipse, je vois toujours un "tag" de branche attaché à la révision originale. – StriplingWarrior

+0

StriplingWarrior: ne pas être attaché à la représentation graphique de la branche. le fait que la balise soit attachée à la révision de base ne change pas le fait que si vous utilisez réellement la balise de branche, vous obtiendrez la révision de pointe de cette branche plutôt que la révision que le graphique associe directement à la balise de branche. –

Questions connexes