Satu atau banyak repositori SVN?

Jika Anda memiliki beberapa proyek yang tidak terkait, apakah ide yang baik untuk meletakkannya di repositori yang sama?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

atau apakah Anda akan membuat repositori baru untuk masing-masing?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

Apa pro dan kontra dari masing-masing? Semua yang saat ini dapat saya pikirkan adalah Anda mendapatkan nomor revisi campuran (jadi apa?), Dan yang tidak dapat Anda gunakan svn:externalskecuali repositori sebenarnya eksternal. (kupikir?)

Alasan saya bertanya adalah karena saya sedang mempertimbangkan untuk menggabungkan beberapa repo saya menjadi satu, karena host SVN saya sudah mulai menagih per repo.

Masalah tunggal vs. ganda bermuara pada preferensi pribadi atau organisasi.

Manajemen multipel vs. tunggal terutama bergantung pada kontrol akses dan pemeliharaan.

Kontrol akses untuk satu repositori dapat dimuat dalam satu file; Banyak repositori mungkin memerlukan banyak file. Pemeliharaan memiliki masalah serupa - satu cadangan besar, atau banyak cadangan kecil.

Saya mengelola sendiri. Ada satu repositori, banyak proyek, masing-masing dengan tag, batang, dan cabangnya sendiri. Jika seseorang menjadi terlalu besar atau saya perlu mengisolasi kode pelanggan secara fisik untuk kenyamanan mereka, saya dapat dengan cepat dan mudah membuat repositori baru.

Saya baru-baru ini berkonsultasi dengan perusahaan yang relatif besar tentang migrasi beberapa sistem kendali kode sumber ke Subversion. Mereka memiliki ~ 50 proyek, mulai dari aplikasi yang sangat kecil hingga perusahaan dan situs web perusahaan mereka. Rencana mereka? Mulailah dengan satu repositori, bermigrasi ke beberapa jika perlu. Migrasi hampir selesai dan mereka masih dalam satu repositori, tidak ada keluhan atau masalah yang dilaporkan karena itu adalah satu repositori.

Ini bukan masalah biner, hitam & putih.

Lakukan apa yang berhasil untuk Anda - jika saya di posisi Anda, saya akan menggabungkan proyek ke dalam satu repositori secepat saya dapat mengetikkan perintah, karena biaya akan menjadi pertimbangan utama di perusahaan saya (sangat, sangat kecil).

JFTR:

nomor revisi di Subversion benar-benar tidak ada artinya di luar repositori. Jika Anda membutuhkan nama yang bermakna untuk revisi, buat TAG

Pesan komitmen mudah difilter menurut jalur dalam repositori, jadi hanya membaca yang terkait dengan proyek tertentu adalah latihan yang sepele.

Edit: Lihat tanggapan Blade untuk rincian tentang menggunakan satu konfigurasi otorisasi / otentikasi untuk SVN.

Untuk kasus spesifik Anda, satu (1) repositori sempurna. Anda akan menghemat banyak uang. Saya selalu mendorong orang untuk menggunakan satu repositori. Karena mirip dengan satu sistem file: Lebih mudah

• Anda akan memiliki satu tempat untuk mencari kode
• Anda akan memiliki satu otorisasi
• Anda akan memiliki satu nomor komit (pernah mencoba membangun proyek yang tersebar di 3 repo?)
• Anda dapat menggunakan kembali perpustakaan umum dengan lebih baik dan melacak kemajuan Anda dalam perpustakaan ini (svn: eksternal adalah PITA dan tidak akan menyelesaikan semua masalah)
• Proyek direncanakan sebagai item yang sangat berbeda, dapat tumbuh bersama dan berbagi fungsi dan antarmuka. Ini akan sangat sulit dicapai dalam banyak repo.

Ada satu poin untuk beberapa repositori: administrasi repo yang besar tidak nyaman. Membuang / memuat repo besar membutuhkan banyak waktu. Tetapi karena Anda tidak melakukan administrasi apa pun, saya pikir itu bukan urusan Anda;)

SVN berskala sangat baik dengan repositori yang lebih besar, tidak ada penurunan bahkan pada repositori yang sangat besar (> 100GB).

Jadi, Anda tidak akan repot dengan satu repositori. Tetapi Anda benar-benar harus memikirkan tata letak repo!

Saya akan menggunakan banyak repositori. Selain masalah akses pengguna, itu juga membuat pencadangan dan pemulihan lebih mudah. Dan jika Anda menemukan diri Anda dalam posisi di mana seseorang ingin membayar Anda untuk kode Anda (dan riwayatnya), lebih mudah untuk memberi mereka tempat penyimpanan repositori.

Saya menyarankan bahwa mengkonsolidasikan repositori hanya karena kebijakan pengisian penyedia hosting Anda bukanlah alasan yang sangat bagus.

Kami menggunakan satu repositori. Satu-satunya kekhawatiran saya adalah skala, tetapi setelah melihat gudang ASF (700k revisi dan penghitungan) saya cukup yakin kinerja tidak akan menjadi masalah.

Proyek kami semua terkait, modul yang saling terkait berbeda yang membentuk sekumpulan dependensi untuk aplikasi tertentu. Untuk alasan ini, satu repositori ideal. Anda mungkin menginginkan batang / cabang / tag terpisah untuk setiap proyek, tetapi Anda masih dapat melakukan perubahan secara atomik di seluruh basis kode Anda dalam satu revisi. Ini luar biasa untuk refactoring.

Ketahuilah bahwa saat membuat keputusan, banyak repo SVN dapat berbagi file konfigurasi yang sama.

Contoh (diambil dari link di atas):

Dalam cangkang:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

File: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

File: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Saya akan membuat repositori terpisah ... Mengapa? Nomor revisi dan pesan komit tidak akan masuk akal jika Anda memiliki banyak proyek yang tidak terkait hanya dalam satu repositori, itu pasti akan menjadi kekacauan besar dalam jangka pendek ....

Kami adalah perusahaan perangkat lunak kecil dan kami menggunakan satu repo untuk semua pengembangan kami. Pohon itu terlihat seperti ini:

/client/<clientname>/<project>/<trunk, branches, tags>

Idenya adalah bahwa kami akan memiliki klien dan pekerjaan internal dalam repo yang sama, tetapi kami akhirnya memiliki perusahaan kami sebagai "klien" itu sendiri.

Ini telah bekerja sangat baik bagi kami, dan kami menggunakan Trac untuk menghubungkannya. Nomor revisi ada di seluruh repo dan tidak spesifik untuk satu proyek, tapi itu tidak fase kami.

Secara pribadi, saya akan membuat repositori baru untuk masing-masing. Itu membuat proses check out lebih sederhana dan membuat administrasi secara keseluruhan lebih mudah, setidaknya berkaitan dengan akses pengguna dan backup. Selain itu, ini menghindari masalah nomor versi global, jadi nomor versi ini berguna untuk semua project.

Sungguh, Anda sebaiknya menggunakan git;)

satu hal tambahan yang perlu dipertimbangkan adalah kenyataan bahwa menggunakan banyak repositori menyebabkan Anda kehilangan kemampuan untuk memiliki pencatatan terpadu (perintah svn log), ini saja akan menjadi alasan yang baik untuk memilih repositori tunggal.

Saya menggunakan TortuisSvn dan menemukan bahwa opsi "Tampilkan Log" adalah alat wajib. meskipun proyek Anda tidak terkait, saya yakin Anda akan menemukan bahwa memiliki informasi lintas proyek global terpusat (jalur, id bug, pesan, dan sebagainya ....) selalu berguna.

Jika Anda berencana atau menggunakan alat seperti trac yang terintegrasi dengan SVN, lebih masuk akal untuk menggunakan satu repo per proyek.

Mirip dengan saran Blade tentang berbagi file, berikut adalah solusi yang sedikit lebih mudah, namun kurang fleksibel. Saya menyiapkan milik kami seperti ini:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

Di "bin", saya menyimpan skrip bernama svn-create.sh yang akan melakukan semua pekerjaan penyiapan untuk membuat repositori kosong. Saya juga menyimpan skrip cadangan di sana.

Dalam "repository_files", saya menyimpan direktori "conf" dan "hooks" yang umum di mana semua repositori memiliki link sym. Lalu, hanya ada satu set file. Namun, ini menghilangkan kemampuan untuk memiliki akses per project yang terperinci tanpa memutus tautan. Itu bukan masalah di mana saya mengatur ini.

Terakhir, saya menyimpan direktori utama / var / svn di bawah kendali sumber dengan mengabaikan semua yang ada di svnroot. Dengan cara itu file repositori dan skrip berada di bawah kendali sumber juga.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Mirip dengan mlambie yang menggunakan satu repo, tetapi melangkah lebih jauh dengan struktur folder untuk memperbesar dengan mudah ke jenis proyek tertentu - proyek berbasis html web vs. cs (C #) vs. sql (skrip buat / eksekusi SQL) vs. xyz ( Bahasa Tertentu Domain seperti afl (Bahasa Formula Amibroker) atau ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Catatan, saya memiliki trunk yang hidup di dalam cabang karena saya memperlakukannya sebagai cabang default. Terkadang satu-satunya rasa sakit adalah ketika Anda ingin membuat proyek lain dengan cepat, Anda perlu membangun struktur tag ProjectName / Branch | Saya menggunakan pengaturan aplikasi hanya sebagai tempat untuk menyimpan file pengaturan Aplikasi tertentu dalam repo sehingga mudah dibagikan kepada orang lain (dan mengganti ClientName ke VendorName dan ProjectName ke AppName dalam struktur folder ini; dan tanda cabang | dapat berguna untuk menandai pengaturan di berbagai jurusan versi produk vendor juga).

Selamat datang di komentar apa pun tentang struktur saya - Saya baru saja mengubahnya menjadi ini dan sejauh ini cukup senang tetapi kadang-kadang merasa beban untuk mempertahankan struktur | tag cabang per proyek - terutama jika proyek tersebut hanyalah pengaturan proyek hanya untuk Uji Unit proyek lain.

Saran saya adalah satu. Kecuali Anda memiliki pengguna berbeda yang mengakses masing-masing, maka saya akan mengatakan gunakan beberapa.

Tapi sekali lagi, itu bukan alasan yang baik untuk menggunakan beberapa.