Bagaimana cara membuat tag SVN dengan benar dari trunk?


282

Saya membuat proyek pertama saya di Subversion . Sejauh ini saya punya

 branches
 tags
 trunk

Saya pikir saya perlu segera membuat cabang tunggal dan memulai dari awal. Perbarui cabang adalah norma.

Saya telah melakukan pekerjaan di trunk dan memindahkan konten ke tag sebagai berikut.

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

Naluriku mengatakan ini benar-benar salah, dan aku harus menjaga hubungan antara file yang digunakan svn copy. File yang saya buat dengan cara ini tidak akan memiliki hubungan satu sama lain, dan saya yakin saya akan kehilangan fitur Subversion. Apakah saya benar?

Haruskah saya menggunakan salinan svn untuk file individual?

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"

Haruskah saya menggunakan salinan svn di seluruh direktori?

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

10
Sayangnya saya tidak membuat semua pilihan dalam kasus ini ... git sangat ajaib.
ojblass

Jawaban:


186

Anda benar karena tidak "benar" untuk menambahkan file ke folder tag.

Anda telah menebak dengan benar bahwa copyini adalah operasi yang digunakan; itu memungkinkan Subversion melacak sejarah file-file ini, dan juga (saya berasumsi) menyimpannya lebih efisien.

Dalam pengalaman saya, yang terbaik adalah melakukan salinan ("snapshots") dari seluruh proyek, yaitu semua file dari lokasi check-out root. Dengan cara itu snapshot dapat berdiri sendiri, sebagai representasi sebenarnya dari seluruh keadaan proyek pada titik waktu tertentu.

Bagian dari "buku" ini menunjukkan bagaimana perintah biasanya digunakan.


15
Versi 1.1 buku ini sudah sangat usang. Berikut tautan yang lebih baik: svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
Quinn Taylor

1
file yang disalin tidak menghabiskan ruang tambahan
Carlos

424

Menggunakan:

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

Steno:

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

36
Saya menandai ini sebagai jawaban. Hanya satu catatan tambahan. Anda bisa mendapatkan revisi dari trunk sebelumnya dan "memberi tag" juga. perintah: svn copy -r 123 " svn.example.com/project/trunk " " svn.example.com/project/tags/1.0 " -m "Menandai, tetapi menggunakan revisi yang lebih lama (123)."
granadaCoder

7
Saya mendapatkan svn: Operasi lokal, non-komit tidak mengambil pesan log atau properti revisi , jadi saya hanya menghapus opsi -m.
Jonny

4
Hanya FYI, pastikan url Anda cocok dengan repositori Anda termasuk http atau https.
Norman H

2
Mengapa \ di akhir baris pertama?
Fractaliste

1
@ Jonny Saya tidak dapat menjalankan perintah di atas tanpa opsi "-m". Saya menggunakan terminal di mac.
Abdurrahman Mubeen Ali

14

Seperti dicatat oleh @victor hugo, cara yang "tepat" adalah menggunakan salinan svn. Namun ada satu peringatan. "Tag" yang dibuat dengan cara itu tidak akan menjadi tag yang benar, itu akan menjadi salinan yang tepat dari revisi yang ditentukan, tetapi itu akan menjadi revisi yang berbeda. Jadi, jika sistem build Anda menggunakan revisi svn entah bagaimana (misalnya, memasukkan angka yang diperoleh dengan 'info svn' ke dalam versi produk yang Anda buat), maka Anda tidak akan dapat membuat produk yang persis sama dari tag (the hasilnya akan memiliki revisi pada tag alih-alih dari kode asli).

Sepertinya dengan desain tidak ada cara di svn untuk membuat tag meta yang benar-benar tepat.


4
Dimungkinkan untuk menggunakan "Last Changed Rev": echo "{ 'svnRev': \"`svn info | awk '/Last Changed Rev:/{print $4}'`\" }" >svnver.txt`
18446744073709551615

Dengan cara ini, dua cabang dengan (tentu saja) angka revisi yang berbeda masih menghasilkan versi perangkat lunak yang sama.
18446744073709551615

1
Ya, Anda benar tentang Last Changed Rev, tetapi itu tidak mengubah fakta bahwa secara desain tidak ada tag asli di Subversion.
Alexander Amelkin

@ 18446744073709551615: Anda dapat menghindari menggunakan awkdan mendapatkan informasi itu langsung dari svn menggunakan --show-itemopsi:svn info --show-item last-changed-revision
Luchostein

12

Gunakan ini saja:

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

(semua dalam satu baris, tentu saja.) Anda harus selalu membuat cabang dari seluruh folder dan konten trunk. Tentu saja mungkin untuk membuat cabang sub-bagian dari bagasi, tetapi ini hampir tidak akan pernah menjadi praktik yang baik. Anda ingin cabang berperilaku persis seperti yang dilakukan bagasi sekarang, dan untuk itu Anda harus mem-cabut seluruh batang.

Lihat ringkasan penggunaan SVN yang lebih baik di blog saya: SVN Essentials , dan SVN Essentials 2


Bisakah Anda menguraikan bagaimana seharusnya jika saya hanya checkoput dari trunk dan saya di dalam dengan skrip saya.
aholbreich

Jika Anda telah memeriksa folder trunk, maka Anda harus menggunakan alamat http repositori. Saya telah memperbarui jawaban untuk mewakili ini sejak memeriksa folder trunk adalah pola yang disarankan.
AgilePro

Bagaimana jawaban ini berbeda dari yang diterima?
Daniel W.


7

@victor hugo dan @unwind benar, dan solusi victor sejauh ini adalah yang paling sederhana. Namun WASPADALAH terhadap eksternal dalam proyek SVN Anda. Jika Anda mereferensi pustaka eksternal, referensi revisi eksternal (apakah tag, atau KEPALA, atau nomor) akan tetap tidak berubah ketika Anda memberi tag pada direktori yang memiliki referensi eksternal.

Dimungkinkan untuk membuat skrip untuk menangani aspek penandaan ini, untuk diskusi tentang topik itu, lihat artikel SO ini: Menandai checkout SVN dengan eksternal


5

Pilihan lain untuk menandai repositori Subversion adalah menambahkan tag ke properti svn: log seperti ini:

   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

Baru-baru ini saya mulai berpikir bahwa ini adalah cara yang paling "benar" untuk menandai. Dengan cara ini Anda tidak membuat revisi tambahan (seperti yang Anda lakukan dengan "svn cp") dan masih dapat dengan mudah mengekstrak semua tag dengan menggunakan grep pada keluaran "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;
                  }'

Selain itu, dengan cara ini Anda dapat menghapus tag secara mulus jika perlu. Jadi tag menjadi informasi meta yang lengkap, dan saya menyukainya.


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

Yang harus Anda lakukan mengubah jalur URL. Perintah ini akan membuat direktori baru "tagDestination". Baris kedua akan memberi tahu Anda rincian kesalahan lengkap jika ada. Buat svn env variabel jika tidak dibuat. Dapat memeriksa (Cmd: - set, Powershell: - Get-ChildItem Env :) Path default adalah "C: \ Program Files \ TortoiseSVN \ bin \ TortoiseProc.exe"


-4

Coba ini. Ini bekerja untuk saya:

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"

1
Ini jelas cara yang salah untuk melakukannya. Tag (Release1.0) harus merupakan salinan direktori sumber (trunk), bukan direktori yang dibuat secara sewenang-wenang. Jika Anda melakukannya dengan cara yang Anda lakukan, Anda kehilangan riwayat direktori sumber itu sendiri dan hanya menyimpan riwayat simpul turunan (file dan direktori).
Alexander Amelkin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.