Je rencontre des problèmes avec les fichiers de sortie en utilisant une étiquette de version et espère que quelqu'un ici peut vous aider.Problèmes d'étiquetage et de vérification des fichiers dans cvs (Sticky tags)
Fondamentalement, mon dépôt est structuré comme celui-ci
module1
- src
- jsp
- conf
module2
- src
- jsp
- conf
Une version peut inclure des changements dans les deux module1 ou module2, ou les deux. Il y a plusieurs développeurs qui pourraient travailler sur n'importe quel fichier dans l'un des modules.
Pour travailler sur une nouvelle version, nous extrayez de la dernière version (par exemple, LIVE-REL-2.4) en utilisant la commande suivante
cvs checkout –r “LIVE-REL-2.4” moduleName
Notez que nous ne consulter à partir trunc. La raison en est que si vous passez à la caisse depuis Trunc, vous incluez des fichiers que d'autres développeurs ont enregistrés mais que vous ne voulez pas inclure dans la prochaine version. Après avoir vérifié la dernière version, nous effectuons les modifications et nous revenons dans les nouveaux fichiers. Pour la livraison, nous étiquetons tous les nouveaux fichiers que nous avons enregistrés avec un tag spécifique au bogue. Nous appliquons ensuite une nouvelle étiquette à chaque fichier de la version actuelle.
cvs tag – r “LIVE-REL-2.4” “LIVE-REL-2.5”
Nous ajoutons ensuite la nouvelle balise de sortie pour les nouveaux fichiers que nous avons vérifié dans
cvs tag –r “BUG434” “LIVE-REL-2.5”
cvs tag –r “BIG435” “LIVE-REL-2.5”
Le ci-dessus assure que la nouvelle version inclura tous les fichiers de la « dernière version livrée » plus corrections de bugs que nous voulons inclure dans la version. Pour vérifier la nouvelle version, nous faisons juste cela
cvs checkout –r “LIVE-REL-2.5” moduleName
Le contrôle de ce qui précède est construit testé et livré. Il y a cependant une certaine confusion quant à savoir si ce processus fonctionne réellement. Nous avons soudainement eu des gens se plaindre qu'ils ne peuvent pas enregistrer de nouveaux fichiers s'ils vérifient par balise. L'erreur qui est généré est illustré ci-dessous
sticky tag `LIVE-REL-2.5' for file `DatabaseFacade.java' is not a branch
Je fais un peu de lecture sur cette erreur mais je nai pas été en mesure de trouver une solution. D'après ce que je rassemble de googler autour, les solutions disponibles sont les suivantes
- exécuter "cvs update -A" sur ces fichiers pour rétablir la copie de travail à la tête.
Cela ne fonctionnerait pas pour moi parce que je ne veux pas libérer les changements qui sont sur la "tête". La révision que je souhaite publier est une version mise à jour de la version précédente. Celui sur le "HEAD" pourrait être celui que quelqu'un a mis à jour et ne sera pas publié pour la prochaine version 3.
- L'étiquette doit être transformé en une branche
Je souhaite que je peux le faire, mais je ne peux pas semblent être en mesure de convaincre l'un de mes patrons que nous devrions soutenir la ramification. Nous ne le soutenons pas, car cela rend apparemment les choses beaucoup plus compliquées qu'elles ne le devraient.Empêche les utilisateurs d'archiver les fichiers qui ne sont pas prêts à être distribués dans la prochaine version. Cela pourrait fonctionner comme je serais alors en mesure de vérifier simplement à partir de «HEAD» chaque fois qu'il y a une nouvelle version.
Maintenant, mes questions sont vraiment comme suit,
- Est-il possible que je peux la caisse en utilisant la procédure ci-dessus sans rencontrer l'erreur « tag collante n'est pas une branche »?
- Y at-il un meilleur moyen que je peux réaliser les mêmes étapes ci-dessus sans avoir à utiliser le branchement? Cela ressemble à l'une des situations les plus courantes dans un environnement de développement. Comment les autres personnes le font sans utiliser de branchement?
- Et enfin, si vous avez des connaissances sur subversion, savez-vous si cela fonctionne de la même manière et si je change de subversion, je vais avoir les mêmes problèmes?
Toute aide sera grandement appréciée.
Bonjour, que fait-il exactement "DatabaseFacade.java> DatabaseFacade.java"? Est-ce juste un moyen de vérifier un nouveau nom de fichier si nécessaire? J'essaie cela et je vois comment ça se passe. Remerciements – ziggy
La commande 'update -p' affiche le fichier sur stdout (évitant ainsi l'uniformité). La commande '> DatabaseFacade.java' redirige la sortie standard vers le fichier DatabaseFacade.java. – Ralph