Metode untuk mengintegrasikan berbagai sistem kontrol versi atau memilih satu di atas yang lain, karena merger dan akuisisi?

11

Perusahaan mengakuisisi perusahaan lain yang menggunakan sistem kontrol versi yang berbeda.

Adakah kebijaksanaan umum tentang bagaimana mengintegrasikan sistem seperti itu bersama-sama, misalnya menggunakan jembatan Subverson-GIT atau bahkan memutuskan untuk menggunakan hanya satu alat di atas yang lain - dan bagaimana bermigrasi antar sistem?

Apakah orang menggunakan seperangkat kriteria untuk pengambilan keputusan seperti itu, misalnya setara dengan tes "Joel" pada pengembangan perangkat lunak?

version-control migration

— therobyouknow
sumber

11

Untuk menjawab pertanyaan migrasi dari pengalaman pribadi beberapa migrasi:

Jangan takut untuk hanya meletakkan versi perangkat lunak saat ini ke dalam sistem kontrol sumber baru sebagai garis dasar dan bekerja dari sana.

Sebagian besar waktu Anda tidak perlu sejarah. Ini berarti satu tugas yang kurang untuk dilakukan selama integrasi dan satu hal yang salah.

File / proyek yang sedang dikembangkan secara aktif akan segera menghasilkan sejarah baru. Jadi, ketika Anda perlu mencari tahu mengapa perubahan dilakukan, kemungkinannya adalah bahwa sejarah akan berada di repositori saat ini karena itu akan menjadi perubahan terbaru.

File / proyek yang stabil sebelum migrasi harus (semua hal dianggap sama) tetap stabil setelah migrasi sehingga Anda tidak perlu merujuk ke riwayat. Kami menemukan bahwa jika kami harus menyelidiki bug dalam file / proyek lama yang memiliki sejarah tidak benar-benar bermanfaat. Selama Anda menyimpan repositori lama tersedia selama 6 bulan / tahun Anda akan memiliki referensi dalam kasus tersebut.

— ChrisF
sumber

+1 titik adil, hanya memigrasikan apa yang Anda butuhkan, meninggalkan versi lama di repositori sebelumnya yang lama. Jangan bermigrasi untuk kepentingannya sendiri. Pendekatan ini merupakan variasi dari pendekatan terhadap pilihan antara pengorganisasian versus pencarian. Jika pencarian bisa mendapatkan apa yang Anda inginkan dengan cepat, setiap saat maka tidak perlu mengatur apa yang Anda cari.

— therobyouknow

1

+1 IMO strategi terbaik. Tetap gunakan hanya satu, yang lain dalam mode read-only-berjaga-jaga

— user281377

1

+1: jawaban yang lebih akurat pada bagian migrasi.

— VonC

1

+1 - cukup sulit untuk memahami kode yang ada apalagi tiga versi terakhir.

— JeffO

1

Kami mengonversi banyak repositori CVS ke SVN menggunakan skrip cvs2svn keren, yang bekerja sangat baik. Saya tidak pernah ingat ada orang yang mencari sejarah di luar 'perubahan terbaru', jadi ini sebenarnya tidak sebanding dengan ruang disk. Jika saya melakukannya lagi, saya hanya akan menandai repo CVS, check in ke SVN sebagai baru dan kemudian menandai repo CVS sebagai read-only.

— JBRWilkinson

4

Di sisi manajerial, pertanyaan utamanya adalah:

dukungan : apakah perusahaan yang mengeluarkan VCS masih ada jika ada masalah.
Sayangnya ini adalah salah satu alasan utama mengapa produk usang seperti ClearCase masih dipertimbangkan (ClearCase sejak 2003 merupakan ... produk IBM )
biaya lisensi : bahkan jika ada alternatif freeware, kadang-kadang "lisensi grup" untuk VCS dapat dinegosiasikan atau sebenarnya termasuk dalam kontrak yang jauh lebih besar termasuk server, jaringan, dukungan, dll ... Lisensi global untuk jenis produk ini dapat berakhir hingga harganya jauh lebih murah dari harga publik.

Di sisi proyek, ini juga merupakan pertanyaan tentang:

administrasi : di server mana Anda akan menginstal VCS (atau banyak VCS jika kita berbicara tentang Git, SVN, dan lainnya)? Dengan kebijakan cadangan apa? Apa DRP (Disastry Recovery Plan)?
dukungan lokal : siapa yang akan mengambil dukungan level 1 ,? level 2?
pengetahuan pasar : apakah Anda yakin untuk menemukan cukup pengembang dan / atau administrator dengan pengetahuan yang tepat untuk memanfaatkan VCS ini dan semua fitur-fiturnya?

Freeware atau tidak, ingat perangkat lunak "gratis" gratis seperti dalam "kebebasan berbicara" (Anda bebas memilih dan menggunakan yang Anda inginkan), tidak seperti dalam "bir gratis" (masih akan menghabiskan banyak uang di server , cadangan, administrasi, dukungan, ...)

Kriteria yang disebutkan di atas adalah awal untuk menentukan VCS apa yang harus disimpan, apa yang harus ditinggalkan.
Namun dalam kasus terakhir, Anda perlu mempertimbangkan:

strategi migrasi : dapatkah Anda mengekspor / mengimpor riwayat proyek dari satu VCS ke yang lain?
strategi jembatan : masuk akal untuk memiliki sejarah dalam dua VCS yang berbeda?
keusangan proyek : jika suatu proyek dalam status pemeliharaan / Akhir Kehidupan, mungkin lebih baik untuk mendukung VCS lama untuk sementara waktu.

— VONC
sumber

+1 jawaban yang bagus, poin-poin singkat menguraikan kriteria yang saya cari, dan penjelasan Anda dengan mereka juga membantu. Saya akan memberi orang lain kesempatan sebelum menerima jawaban. Terima kasih.

— therobyouknow

1

Apakah Anda benar-benar perlu mengintegrasikan sistem yang berbeda? Dalam tim kami, setiap proyek tinggal di repositori sendiri, dan sejarahnya independen. Kami tidak memiliki masalah di sini untuk bekerja dengan beberapa proyek di bawah subversi dan beberapa lainnya di bawah lincah, bahkan jika ada ketergantungan di antara mereka.

Jika Anda memilih untuk bermigrasi dari satu VCS ke yang lain, lihat alat konversi yang tersedia. Dari pengalaman saya, tidak ada alasan teknis untuk menghapus sejarah proyek.

Edit

Saya pikir saya mengerti sesuatu, yang tersirat dalam pertanyaan dan jawaban lainnya. Itu fakta bahwa VCS juga digunakan untuk mengelola dependensi. Saya tahu itu cukup umum untuk menggunakan fitur VCS ingin svn:externalsmengintegrasikan satu repo (ketergantungan) dengan yang lain.

Saya pikir alasan (teknis) tim kami tidak merasa perlu menjembatani (atau mengintegrasikan) 2 sistem kami yang berbeda adalah karena kami memiliki alat terpisah untuk mengelola dependensi. Repo kami tidak saling kenal.

— barjak
sumber

Perlu mengintegrasikan sistem yang berbeda? Ya jika karya satu tim digunakan oleh tim lain. Integrasi bisa ketat atau hilang tergantung pada tingkat kebutuhan dan sumber daya staf yang tersedia. Tidak jika proyek sepenuhnya independen. Satu-satunya kekhawatiran yang tersisa adalah mendukung lebih dari satu sistem dan apakah itu dianggap sebagai hal yang baik atau buruk. Baik jika kita menerima bahwa kita hidup dalam dunia komputasi yang bervariasi atau buruk jika kita berpikir bahwa kita harus fokus dan menunjukkan ketegasan untuk kepentingan mereka sendiri, dengan memilih satu alat itu sendiri yang mungkin terlalu solipstistik!

— therobyouknow

PS. +1 Lucky you, barjak, karena berada di organisasi yang mentolerir lingkungan komputasi yang bervariasi.

— therobyouknow

0

Banyak jawaban bagus. Satu hal lain untuk dipikirkan adalah jangan biarkan anggota tim lolos dengan berpikir mengganti VC adalah masalah besar. Akan ada kemunduran dengan migrasi, kurva belajar, dll., Tetapi jika mereka memiliki terlalu banyak masalah, mereka perlu mempertanyakan tingkat kemampuan dan / atau kerja sama mereka.

— JeffO
sumber

+1 Realisme di sini. Orang-orang perlu menahan keberanian, berani, dan melanjutkan. Risiko harus didefinisikan dengan baik. Satu pembelajaran yang saya lihat dan dengar orang lain katakan di tempat kerja saya adalah bahwa kadang-kadang kita tidak bekerja cukup keras untuk mengurangi ketidakpastian / dengan jelas mendefinisikan risiko / kemungkinan sebelum kita terlibat. Tampaknya ada banyak waktu untuk iterasi yang salah / perbaiki tetapi tidak cukup waktu untuk memperbaikinya pertama kali. Memperbaiki masalah dihargai dan dilihat sebagai aktivitas yang sedang berlangsung, bahkan jika kadang-kadang mereka tidak perlu.

— therobyouknow

1

Itu tergantung pada VCS yang dimaksud dan seberapa baik migrasi dilakukan. Pindah dari Git atau bahkan CVS ke VCS yang terkunci akan menjadi sangat menggelegar.

— David Thornley