Wie erstelle ich ein SVN-Tag richtig aus dem Trunk?

Ich erstelle mein erstes Projekt in Subversion . Soweit habe ich

 branches
 tags
 trunk

Ich denke, ich muss sofort Zweige singulär machen und von vorne anfangen. Zweigstellen aktualisieren ist die Norm.

Ich habe im Kofferraum gearbeitet und den Inhalt wie folgt in Tags verschoben.

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

Mein Bauch sagt mir, dass dies völlig falsch ist, und ich sollte eine Beziehung zwischen den verwendeten Dateien aufrechterhalten svn copy. Die Dateien, die ich auf diese Weise erstelle, haben keine Beziehung zueinander, und ich bin sicher, dass ich die Subversion-Funktionen verpassen werde. Hab ich recht?

Soll ich für die einzelnen Dateien eine SVN-Kopie verwenden?

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"

Soll ich svn copy für das gesamte Verzeichnis verwenden?

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

Sie haben insofern Recht, als es nicht "richtig" ist, Dateien zum Tags-Ordner hinzuzufügen.

Sie haben richtig geraten, dass dies copydie zu verwendende Operation ist. Damit kann Subversion den Verlauf dieser Dateien verfolgen und sie (ich nehme an) viel effizienter speichern.

Nach meiner Erfahrung ist es am besten, Kopien ("Schnappschüsse") ganzer Projekte zu erstellen, dh aller Dateien vom Stammauscheckort. Auf diese Weise kann der Schnappschuss als eigenständige Darstellung des gesamten Projektstatus zu einem bestimmten Zeitpunkt für sich allein stehen.

Dieser Teil von "Das Buch" zeigt, wie der Befehl normalerweise verwendet wird.

Verwenden:

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

Kurzschrift:

cd /path/to/project
svn copy ^/trunk ^/tags/1.0 -m "Release 1.0"

Wie von @victor hugo festgestellt, ist die "richtige" Methode die Verwendung von svn copy. Es gibt jedoch eine Einschränkung. Das auf diese Weise erstellte "Tag" ist kein echtes Tag, sondern eine exakte Kopie der angegebenen Revision, es handelt sich jedoch um eine andere Revision. Wenn Ihr Build-System also irgendwie die svn-Revision verwendet (z. B. die mit 'svn info' erhaltene Nummer in die Version des von Ihnen erstellten Produkts einbezieht), können Sie nicht genau dasselbe Produkt aus einem Tag (dem Das Ergebnis enthält die Überarbeitung des Tags anstelle des ursprünglichen Codes.

Es sieht so aus, als ob es in svn keine Möglichkeit gibt, ein wirklich richtiges Meta-Tag zu erstellen.

Verwenden Sie einfach dies:

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

(Natürlich alles in einer Zeile.) Sie sollten immer einen Zweig des gesamten Trunk-Ordners und des Inhalts erstellen. Es ist natürlich möglich, Teile des Rumpfes zu verzweigen, aber dies wird fast nie eine gute Praxis sein. Sie möchten, dass sich der Zweig genau so verhält wie der Trunk jetzt, und dazu müssen Sie den gesamten Trunk verzweigen.

Eine bessere Zusammenfassung der SVN-Nutzung finden Sie in meinem Blog: SVN Essentials und SVN Essentials 2

Könnte Schildkröte verwenden:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html

@ Victor Hugo und @ Unwind sind korrekt, und die Lösung von Victor ist bei weitem die einfachste. Achten Sie jedoch auf externe Elemente in Ihrem SVN-Projekt. Wenn Sie auf externe Bibliotheken verweisen, bleibt die Revisionsreferenz der externen Bibliothek (ob Tag, HEAD oder Nummer) unverändert, wenn Sie Verzeichnisse mit externen Referenzen kennzeichnen.

Es ist möglich, ein Skript zu erstellen, das diesen Aspekt des Tagging behandelt. Eine Diskussion zu diesem Thema finden Sie in diesem SO-Artikel: Taggen eines SVN-Checkout mit externen Elementen

Eine weitere Option zum Markieren eines Subversion-Repositorys besteht darin, das Tag der Eigenschaft svn: log wie folgt hinzuzufügen:

   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

Ich habe kürzlich angefangen zu denken, dass dies der "richtige" Weg ist, um zu markieren. Auf diese Weise erstellen Sie keine zusätzlichen Revisionen (wie bei "svn cp") und können trotzdem alle Tags einfach extrahieren, indem Sie grep für die Ausgabe von "svn log" verwenden:

   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;
                  }'

Auf diese Weise können Sie Tags bei Bedarf nahtlos löschen . So werden die Tags zu einer vollständigen Meta-Information, und ich mag es.

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

Alles was Sie tun müssen, um den URL-Pfad zu ändern. Dieser Befehl erstellt das neue Verzeichnis "tagDestination". In der zweiten Zeile werden Sie gegebenenfalls über die vollständigen Fehlerdetails informiert. Erstellen Sie die Variable svn env, wenn sie nicht erstellt wurde. Kann überprüfen (Cmd: - set, Powershell: - Get-ChildItem Env :) Der Standardpfad lautet "C: \ Programme \ TortoiseSVN \ bin \ TortoiseProc.exe".

Versuche dies. Für mich geht das:

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"