Comment créer correctement une balise SVN à partir d'un tronc?

282

Je crée mon premier projet dans Subversion . Jusqu'à présent, j'ai

 branches
 tags
 trunk

Je pense que je dois immédiatement rendre les branches singulières et recommencer. La mise à jour des branches est la norme.

J'ai fait du travail dans le coffre et déplacé le contenu vers les balises comme suit.

mkdir tags/1.0
cp -rf trunk/* tags/1.0
svn add tags/1.0
svn commit -m " create a first tagged version"

Mon instinct me dit que c'est totalement faux, et je dois maintenir une certaine relation entre les fichiers à l'aide svn copy. Les fichiers que je crée de cette manière n'auront aucune relation les uns avec les autres, et je suis sûr que je vais manquer les fonctionnalités de Subversion. Ai-je raison?

Dois-je utiliser la copie svn pour les fichiers individuels?

mkdir tags/1.0
svn add tags/1.0
svn copy trunk/file1 tags/1.0
svn copy trunk/file2 tags/1.0
svn copy trunk/file3 tags/1.0
svn commit -m " create a first tagged version"

Dois-je utiliser la copie svn sur l'ensemble du répertoire?

svn copy cp -rf trunk tags/1.0
svn commit -m " create a first tagged version"
ojblass
la source
10
Malheureusement, je ne fais pas tous les choix dans ce cas ... git est sacrément magique.
ojblass

Réponses:

186

Vous avez raison en ce qu'il n'est pas "correct" d'ajouter des fichiers au dossier des balises.

Vous avez correctement deviné que copyc'est l'opération à utiliser; il permet à Subversion de garder une trace de l'historique de ces fichiers, et aussi (je suppose) de les stocker beaucoup plus efficacement.

D'après mon expérience, il est préférable de faire des copies («instantanés») de projets entiers, c'est-à-dire tous les fichiers à partir de l'emplacement d'extraction racine. De cette façon, l'instantané peut se suffire à lui-même, comme une véritable représentation de l'état du projet entier à un moment donné.

Cette partie du "livre" montre comment la commande est généralement utilisée.

se détendre
la source
15
La version 1.1 du livre est terriblement dépassée. Voici un meilleur lien: svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
Quinn Taylor
1
les fichiers copiés ne dépensent pas d'espace supplémentaire
Carlos
424

Utilisation:

svn copy http://svn.example.com/project/trunk \
      http://svn.example.com/project/tags/1.0 -m "Release 1.0"

Sténographie:

cd /path/to/project
svn copy ^/trunk ^/tags/1.0 -m "Release 1.0"
Victor Hugo
la source
36
J'ai marqué cela comme réponse. Juste une note supplémentaire. Vous pouvez obtenir une révision précédente du tronc et le "tag" ainsi. la commande: svn copy -r 123 " svn.example.com/project/trunk " " svn.example.com/project/tags/1.0 " -m "Balisage, mais en utilisant une révision plus ancienne (123)."
granadaCoder
7
Je reçois svn: les opérations locales non validées ne prennent pas de message de journal ni de propriétés de révision , je supprime donc simplement l'option -m.
Jonny
4
Juste un info, assurez-vous que votre URL correspond à votre référentiel, y compris http ou https.
Norman H
2
Pourquoi le \ à la fin de la première ligne?
Fractaliste
1
@Jonny Je ne peux pas exécuter la commande ci-dessus sans l'option "-m". J'utilise un terminal sur mac.
Abdurrahman Mubeen Ali
14

Comme l'a noté @victor hugo, la méthode "appropriée" consiste à utiliser la copie svn. Il y a cependant une mise en garde. La "balise" ainsi créée ne sera pas une vraie balise, ce sera une copie exacte de la révision spécifiée, mais ce sera une révision différente elle-même. Donc, si votre système de construction utilise la révision svn d'une manière ou d'une autre (par exemple, incorpore le nombre obtenu avec 'svn info' dans la version du produit que vous construisez), alors vous ne pourrez pas construire exactement le même produit à partir d'une balise (la Le résultat aura la révision de la balise au lieu de celle du code d'origine).

Il semble que par conception, il n'existe aucun moyen dans svn de créer une balise META vraiment appropriée.

Alexander Amelkin
la source
4
Il est possible d'utiliser "Last Changed Rev": echo "{ 'svnRev': \"`svn info | awk '/Last Changed Rev:/{print $4}'`\" }" >svnver.txt`
18446744073709551615
De cette façon, deux branches avec (bien sûr) des numéros de révision différents produisent toujours la même version du logiciel.
18446744073709551615
1
Oui, vous avez raison à propos de Last Changed Rev, mais cela ne change pas le fait que par conception, il n'y a pas de véritables balises dans Subversion.
Alexander Amelkin
@ 18446744073709551615: Vous pouvez éviter d'utiliser awket obtenir ces informations directement de svn en utilisant l' --show-itemoption:svn info --show-item last-changed-revision
Luchostein
12

Utilisez simplement ceci:

svn  copy  http://svn.example.com/project/trunk  
           http://svn.example.com/project/branches/release-1
           -m  "branch for release 1.0"

(le tout sur une seule ligne, bien sûr.) Vous devez toujours créer une branche de l'ensemble du dossier de tronc et de son contenu. Il est bien sûr possible de dériver des sous-parties du tronc, mais ce ne sera presque jamais une bonne pratique. Vous voulez que la branche se comporte exactement comme le tronc le fait maintenant, et pour que cela se produise, vous devez dériver la totalité du tronc.

Voir un meilleur résumé de l'utilisation de SVN sur mon blog: SVN Essentials et SVN Essentials 2

AgilePro
la source
Pouvez-vous expliquer à quoi cela devrait ressembler si je vérifie uniquement à partir du tronc et que je suis à l'intérieur avec mon script.
aholbreich
Si vous avez extrait le dossier trunk, vous devez utiliser l'adresse http du référentiel. J'ai mis à jour la réponse pour représenter cela, car la vérification du dossier de coffre est le modèle recommandé.
AgilePro
En quoi cette réponse est-elle différente de la réponse acceptée?
Daniel W.
7

@victor hugo et @unwind sont corrects, et la solution de Victor est de loin la plus simple. Méfiez-vous toutefois des éléments externes dans votre projet SVN. Si vous référencez des bibliothèques externes, la référence de révision externe (qu'il s'agisse d'une balise, ou HEAD, ou d'un numéro) restera inchangée lorsque vous balisez des répertoires qui ont des références externes.

Il est possible de créer un script pour gérer cet aspect du balisage, pour une discussion sur ce sujet, voir cet article SO: Baliser un checkout SVN avec des externes

MOK9
la source
5

Une autre option pour baliser un référentiel Subversion consiste à ajouter la balise à la propriété svn: log comme ceci:

   echo "TAG: your_tag_text" > newlog
   svn propget $REPO --revprop -r $tagged_revision >> newlog
   svn propset $REPO --revprop -r $tagged_revision -F newlog
   rm newlog

J'ai récemment commencé à penser que c'était la façon la plus "correcte" de marquer. De cette façon, vous ne créez pas de révisions supplémentaires (comme vous le faites avec "svn cp") et vous pouvez toujours extraire facilement toutes les balises en utilisant grep sur la sortie "svn log":

   svn log | awk '/----/ {
                      expect_rev=1;
                      expect_tag=0;
                  }
                  /^r[[:digit:]]+/ {
                      if(expect_rev) {
                          rev=$1;
                          expect_tag=1;
                          expect_rev=0;
                      }
                  }
                  /^TAG:/ {
                      if(expect_tag) {
                          print "Revision "rev", Tag: "$2;
                      }
                      expect_tag=0;
                  }'

De cette façon, vous pouvez également supprimer les balises de manière transparente si vous en avez besoin. Les balises deviennent donc une méta-information complète, et j'aime ça.

Alexander Amelkin
la source
0
svn copy http://URL/svn/trukSource http://URL/svn/tagDestination -m "Test tag code" 
  $error[0].Exception | Select-object Data

Tout ce que vous avez à faire est de changer le chemin de l'URL. Cette commande va créer un nouveau répertoire "tagDestination". La deuxième ligne vous fera connaître les détails complets de l'erreur, le cas échéant. Créez la variable svn env si elle n'est pas créée. Peut vérifier (Cmd: - set, Powershell: - Get-ChildItem Env :) Le chemin par défaut est "C: \ Program Files \ TortoiseSVN \ bin \ TortoiseProc.exe"

Ashu
la source
-4

Essaye ça. Ça marche pour moi:

mkdir <repos>/tags/Release1.0
svn commit <repos>/tags/Release1.0 
svn copy <repos>/trunk/* <repos>/tag/Release1.0
svn commit <repos/tags/Release1.0 -m "Tagging Release1.0"
iboubuntu
la source
1
C'est définitivement une mauvaise façon de procéder. La balise (Release1.0) doit être une copie du répertoire source (tronc), pas un répertoire créé arbitrairement. Si vous le faites comme vous l'avez fait, vous perdez l'historique du répertoire source lui-même et ne conservez que l'historique des nœuds descendants (fichiers et répertoires).
Alexander Amelkin