Haruskah saya menyimpan kode yang dihasilkan di kontrol sumber

Ini adalah debat yang saya ikuti. Saya ingin mendapatkan lebih banyak pendapat dan sudut pandang.

Kami memiliki beberapa kelas yang dihasilkan dalam waktu pembuatan untuk menangani operasi DB (dalam kasus khusus ini, dengan SubSonic, tapi saya rasa itu tidak terlalu penting untuk pertanyaan itu). Generasi ditetapkan sebagai langkah pra-bangun di Visual Studio. Jadi setiap kali developer (atau proses build resmi) menjalankan build, class ini dibuat, lalu dikompilasi ke dalam project.

Sekarang beberapa orang mengklaim, bahwa menyimpan kelas-kelas ini di kontrol sumber dapat menyebabkan kebingungan, jika kode yang Anda dapatkan, tidak cocok dengan apa yang akan dibuat di lingkungan Anda sendiri.

Saya ingin memiliki cara untuk melacak kembali sejarah kode, bahkan jika biasanya diperlakukan sebagai kotak hitam.

Adakah argumen atau argumen balasan?

Saya tidak akan memilih jawaban yang diterima pada saat ini karena alasan yang disebutkan di atas.

Menyimpannya dalam kendali sumber lebih merepotkan daripada nilainya.

Anda harus melakukan commit setiap kali Anda melakukan build agar nilainya menjadi berapa pun.

Umumnya kami meninggalkan kode yang dihasilkan (idl, jaxb stuff, dll) di luar kendali sumber tempat saya bekerja dan itu tidak pernah menjadi masalah

Taruh di kontrol kode sumber. Keuntungan memiliki riwayat dari semua yang Anda tulis tersedia untuk pengembang di masa mendatang lebih besar daripada rasa sakit kecil karena sesekali membangun kembali setelah sinkronisasi.

Setiap kali saya ingin menampilkan perubahan pada pohon sumber di repo pribadi saya, semua 'file yang dihasilkan' akan muncul sebagai telah berubah dan perlu comitting.

Saya lebih suka memiliki daftar modifikasi yang lebih bersih yang hanya mencakup pembaruan nyata yang dilakukan, dan bukan perubahan yang dibuat secara otomatis.

Biarkan mereka keluar, dan kemudian setelah membangun, tambahkan 'abaikan' pada setiap file yang dihasilkan.

Lihatlah dengan cara ini: apakah Anda memeriksa file objek Anda ke dalam kontrol sumber? File sumber yang dihasilkan adalah artefak build seperti file objek, pustaka, dan file yang dapat dieksekusi. Mereka harus diperlakukan sama. Sebagian besar akan berpendapat bahwa Anda tidak boleh memeriksa file objek yang dihasilkan dan file yang dapat dieksekusi ke dalam kontrol sumber. Argumen yang sama berlaku untuk sumber yang dihasilkan.

Jika Anda perlu melihat versi historis dari file yang dihasilkan, Anda dapat menyinkronkan ke versi historis dari sumbernya dan membuatnya kembali.

Memeriksa file yang dihasilkan dalam bentuk apa pun ke dalam kontrol sumber mirip dengan denormalisasi database. Ada kadang-kadang alasan untuk melakukan hal ini (biasanya untuk kinerja), tetapi ini harus dilakukan hanya dengan hati-hati karena menjadi jauh lebih sulit untuk mempertahankan kebenaran dan konsistensi sekali data denormalized.

Saya akan mengatakan bahwa Anda harus menghindari menambahkan kode yang dihasilkan (atau artefak lain) ke kontrol sumber. Jika kode yang dihasilkan sama untuk input yang diberikan maka Anda bisa memeriksa versi yang ingin Anda diff dan menghasilkan kode untuk perbandingan.

Saya menyebutnya prinsip KERING. Jika Anda sudah memiliki "file sumber" di repositori yang digunakan untuk menghasilkan file kode ini pada waktu pembuatan, tidak perlu ada kode yang sama yang dikomit "dua kali".

Juga, Anda dapat menghindari beberapa masalah dengan cara ini jika misalnya pembuatan kode rusak suatu hari nanti.

Tidak, karena tiga alasan.

1. Kode sumber adalah segalanya yang diperlukan dan cukup untuk mereproduksi snapshot aplikasi Anda pada beberapa titik waktu saat ini atau sebelumnya - tidak lebih dan tidak kurang. Sebagian dari apa yang tersirat di sini adalah bahwa seseorang bertanggung jawab atas segala sesuatu yang masuk. Umumnya saya senang bertanggung jawab atas kode yang saya tulis, tetapi bukan kode yang dihasilkan sebagai konsekuensi dari apa yang saya tulis.

2. Saya tidak ingin seseorang tergoda untuk mencoba membuat pintasan dari sumber utama dengan menggunakan kode perantara yang mungkin atau mungkin tidak terkini (dan yang lebih penting saya tidak ingin menerima tanggung jawab.) Dan bukankah itu juga menggoda beberapa orang untuk terjebak dalam proses yang tidak berarti tentang konflik debug dalam kode menengah berdasarkan build parsial.

3. Setelah itu dalam kendali sumber, saya menerima tanggung jawab untuk a. itu ada di sana, b. itu sedang berlangsung, dan c. itu dapat diintegrasikan dengan andal dengan segala sesuatu di sana. Itu termasuk menghapusnya saat saya tidak lagi menggunakannya. Semakin sedikit tanggung jawab itu semakin baik.

Saya benar-benar tidak berpikir Anda harus memeriksanya.

Tentunya setiap perubahan dalam kode yang dihasilkan akan menjadi gangguan - perubahan antar lingkungan, atau perubahan sebagai akibat dari sesuatu yang lain - misalnya perubahan dalam DB Anda. Jika skrip pembuatan DB Anda (atau dependensi lainnya) berada dalam kontrol sumber, mengapa Anda membutuhkan skrip yang dihasilkan juga?

Aturan umumnya adalah tidak , tetapi jika perlu waktu untuk menghasilkan kode (karena akses DB, layanan web, dll.) Maka Anda mungkin ingin menyimpan versi yang di-cache di kontrol sumber dan menyelamatkan semua orang dari rasa sakit.

Perkakas Anda juga perlu menyadari hal ini dan menangani check-out dari kontrol sumber bila diperlukan, terlalu banyak alat memutuskan untuk check-out dari kontrol sumber tanpa alasan apa pun.
Alat yang baik akan menggunakan versi yang di-cache tanpa menyentuhnya (atau memodifikasi langkah waktu pada file).

Anda juga perlu memberi peringatan besar di dalam kode yang dihasilkan agar orang tidak mengubah file, peringatan di atas tidak cukup, Anda harus mengulanginya setiap lusin baris.

Kami juga tidak menyimpan kode DB yang dibuat: karena dibuat, Anda bisa mendapatkannya sesuka hati pada versi apa pun dari file sumber. Menyimpannya sama seperti menyimpan bytecode atau semacamnya.

Sekarang, Anda perlu memastikan pembuat kode yang digunakan pada versi tertentu tersedia! Versi yang lebih baru dapat menghasilkan kode yang berbeda ...

Biarkan saja.

Jika Anda memeriksa file yang dihasilkan, Anda melakukan sesuatu yang salah. Apa yang salah mungkin berbeda, bisa jadi proses pembuatan Anda tidak efisien, atau sesuatu yang lain, tetapi saya tidak pernah melihatnya sebagai ide yang bagus. Sejarah harus dikaitkan dengan file sumber, bukan yang dihasilkan.

Itu hanya membuat pusing bagi orang-orang yang akhirnya mencoba menyelesaikan perbedaan, menemukan file yang tidak lagi dibuat oleh build dan kemudian menghapusnya, dll.

Dunia kesakitan menanti mereka yang memeriksa file yang dibuat!

Ada kasus khusus di mana Anda ingin memeriksa file yang Anda buat: ketika Anda mungkin perlu membangun sistem di mana alat yang digunakan untuk menghasilkan file lain tidak tersedia. Contoh klasik dari ini, dan yang saya kerjakan, adalah kode Lex dan Yacc. Karena kami mengembangkan sistem runtime yang harus dibangun dan dijalankan pada berbagai macam platform dan arsitektur, kami hanya dapat mengandalkan sistem target untuk memiliki kompiler C dan C ++, bukan alat yang diperlukan untuk menghasilkan kode lexing / parsing untuk definisi antarmuka kami Penerjemah. Jadi, ketika kami mengubah tata bahasa kami, kami memeriksa kode yang dihasilkan untuk menguraikannya.

datang agak terlambat ... pokoknya ...

Apakah Anda akan meletakkan file perantara kompiler ke dalam kontrol versi sumber? Dalam hal pembuatan kode, menurut definisi kode sumber adalah input dari generator sedangkan kode yang dihasilkan dapat dianggap sebagai file perantara antara sumber "nyata" dan aplikasi yang dibangun.

Jadi saya akan mengatakan: jangan meletakkan kode yang dihasilkan di bawah kontrol versi, tetapi generator dan inputnya.

Secara konkret, saya bekerja dengan generator kode yang saya tulis: Saya tidak pernah harus memelihara kode sumber yang dihasilkan di bawah kendali versi. Saya bahkan akan mengatakan bahwa karena generator mencapai tingkat kematangan tertentu, saya tidak perlu mengamati konten kode yang dihasilkan meskipun input (misalnya deskripsi model) berubah.

Dalam beberapa proyek saya menambahkan kode yang dihasilkan ke kontrol sumber, tetapi itu sangat tergantung. Pedoman dasar saya adalah jika kode yang dihasilkan merupakan bagian intrinsik dari kompilator maka saya tidak akan menambahkannya. Jika kode yang dihasilkan berasal dari alat eksternal, seperti SubSonic dalam kasus ini, maka saya akan menambahkan if ke kontrol sumber. Jika Anda mengupgrade komponen secara berkala maka saya ingin mengetahui perubahan dalam sumber yang dihasilkan jika ada bug atau masalah yang muncul.

Sejauh kode yang dihasilkan perlu diperiksa, skenario terburuk adalah membedakan file secara manual dan mengembalikan file jika perlu. Jika Anda menggunakan svn, Anda dapat menambahkan hook pra-komit di svn untuk menolak komit jika file belum benar-benar berubah.

Tugas manajemen konfigurasi (dimana kontrol versinya hanya satu bagian) adalah mampu melakukan hal berikut:

• Ketahui perubahan dan perbaikan bug mana yang telah diterapkan pada setiap build yang dikirimkan.
• Mampu mereproduksi persis semua build yang dikirim, mulai dari kode sumber aslinya. Kode yang dibuat secara otomatis tidak dihitung sebagai "kode sumber" apa pun bahasanya.

Yang pertama memastikan bahwa ketika Anda memberi tahu klien atau pengguna akhir "bug yang Anda laporkan minggu lalu telah diperbaiki dan fitur baru telah ditambahkan" mereka tidak kembali dua jam kemudian dan berkata "tidak, belum". Itu juga memastikan mereka tidak mengatakan "Mengapa melakukan X? Kami tidak pernah meminta X".

Yang kedua berarti bahwa ketika klien atau pengguna akhir melaporkan bug di beberapa versi yang Anda keluarkan setahun yang lalu, Anda dapat kembali ke versi itu, mereproduksi bug, memperbaikinya, dan membuktikan bahwa itu adalah perbaikan Anda telah menghilangkan bug daripada beberapa gangguan pada kompilator dan perbaikan lainnya.

Ini berarti kompilator, pustaka, dll. Anda juga harus menjadi bagian dari CM.

Jadi sekarang untuk menjawab pertanyaan Anda: jika Anda dapat melakukan semua hal di atas maka Anda tidak perlu merekam representasi perantara, karena Anda dijamin mendapatkan jawaban yang sama. Jika Anda tidak dapat melakukan semua hal di atas, maka semua taruhan dibatalkan karena Anda tidak dapat menjamin untuk melakukan hal yang sama dua kali dan mendapatkan jawaban yang sama. Jadi Anda sebaiknya meletakkan semua file .o Anda di bawah kontrol versi juga.

Itu sangat tergantung. Pada akhirnya, tujuannya adalah untuk dapat mereproduksi apa yang Anda miliki jika diperlukan. Jika Anda dapat meregenerasi binari dengan tepat, Anda tidak perlu menyimpannya. tetapi Anda perlu ingat bahwa untuk membuat ulang barang-barang Anda, Anda mungkin memerlukan konfigurasi persis seperti yang Anda lakukan di tempat pertama, dan itu tidak hanya berarti kode sumber Anda, tetapi juga lingkungan build Anda, IDE Anda, bahkan mungkin perpustakaan lain , generator atau barang, dalam konfigurasi yang tepat (versi) yang Anda gunakan.

Saya mengalami masalah dalam proyek jika kami meningkatkan lingkungan pembuatan kami ke versi yang lebih baru atau bahkan ke vendor lain, di mana kami tidak dapat membuat ulang binari persis seperti yang kami miliki sebelumnya. Ini sangat merepotkan ketika binari yang akan digunakan bergantung pada jenis hash, terutama di lingkungan yang aman, dan file yang dibuat kembali entah bagaimana berbeda karena peningkatan kompiler atau apa pun.

Jadi, apakah Anda akan menyimpan kode yang dihasilkan: Saya akan mengatakan tidak. Biner atau kiriman yang dirilis, termasuk alat yang Anda reproduksi dengan saya akan simpan. Dan kemudian, tidak perlu menyimpannya di kontrol sumber, cukup buat cadangan file tersebut dengan baik.

Jawaban yang benar adalah "Tergantung". Itu tergantung pada apa kebutuhan klien. Jika Anda dapat memutar kembali kode ke rilis tertentu dan mempertahankan setiap audit eksternal tanpanya, maka Anda masih belum yakin. Sebagai pengembang, kita perlu mempertimbangkan tidak hanya 'kebisingan', rasa sakit, dan ruang disk, tetapi fakta bahwa kita ditugaskan dengan peran menghasilkan kekayaan intelektual dan mungkin ada konsekuensi hukum. Dapatkah Anda membuktikan kepada hakim bahwa Anda dapat membuat ulang situs web persis seperti yang dilihat pelanggan dua tahun lalu?

Saya tidak menyarankan Anda menyimpan atau tidak menyimpan file gen, dengan cara apa pun Anda memutuskan apakah Anda tidak melibatkan Pakar Subjek dari keputusan Anda mungkin salah.

Dua sen saya.

Ada argumen baik yang mendukung dan menentang yang disajikan di sini. Sebagai catatan, saya membangun sistem generasi T4 di Visual Studio dan opsi default out-of-the-box kami menyebabkan kode yang dihasilkan diperiksa. Anda harus bekerja sedikit lebih keras jika Anda memilih untuk tidak check-in.

Bagi saya, pertimbangan utamanya adalah membedakan output yang dihasilkan ketika input atau generator itu sendiri diperbarui.

Jika Anda tidak memiliki keluaran yang diperiksa, maka Anda harus mengambil salinan dari semua kode yang dihasilkan sebelum memutakhirkan generator atau mengubah masukan agar dapat membandingkannya dengan keluaran dari versi baru. Saya pikir ini adalah proses yang cukup membosankan, tetapi dengan keluaran yang dicentang, ini masalah sederhana untuk membedakan keluaran baru terhadap repositori.

Pada titik ini, masuk akal untuk bertanya "Mengapa Anda peduli dengan perubahan dalam kode yang dihasilkan?" (Terutama dibandingkan dengan kode objek.) Saya percaya ada beberapa alasan utama, yang turun ke keadaan seni saat ini daripada masalah yang melekat.

1. Anda membuat kode tulisan tangan yang terhubung erat dengan kode yang dihasilkan. Itu tidak terjadi secara keseluruhan dengan file obj hari ini. Ketika kode yang dihasilkan berubah, sayangnya cukup sering terjadi beberapa kode tulisan tangan perlu diubah agar cocok. Orang sering tidak mengamati tingkat kompatibilitas mundur yang tinggi dengan poin ekstensibilitas dalam kode yang dihasilkan.

2. Kode yang dihasilkan hanya mengubah perilakunya. Anda tidak akan mentolerir hal ini dari kompiler, tetapi sejujurnya, generator kode tingkat aplikasi menargetkan bidang masalah yang berbeda dengan solusi yang lebih luas yang dapat diterima. Penting untuk melihat apakah asumsi yang Anda buat tentang perilaku sebelumnya sekarang rusak.

3. Anda hanya tidak 100% mempercayai output generator Anda dari rilis ke rilis. Ada banyak nilai yang bisa didapat dari alat generator bahkan jika alat itu tidak dibangun dan dipelihara dengan ketatnya vendor kompiler Anda. Rilis 1.0 mungkin sangat stabil untuk aplikasi Anda, tetapi mungkin 1.1 memiliki beberapa gangguan untuk kasus penggunaan Anda sekarang. Atau Anda mengubah nilai input dan mendapati bahwa Anda sedang menjalankan generator baru yang belum pernah Anda gunakan sebelumnya - kemungkinan besar Anda akan terkejut dengan hasilnya.

Pada dasarnya semua hal ini bermuara pada kedewasaan alat - sebagian besar pembuat kode aplikasi bisnis tidak mendekati level yang dimiliki kompiler atau bahkan alat level lex / yacc selama bertahun-tahun.

Kedua belah pihak memiliki argumen yang valid dan masuk akal, dan sulit untuk menyepakati sesuatu yang sama. Sistem Kontrol Versi (VCS) melacak file yang dimasukkan oleh pengembang ke dalamnya, dan memiliki asumsi bahwa file di dalam VCS dibuat dengan tangan oleh pengembang, dan pengembang tertarik dengan riwayat dan perubahan antara revisi file apa pun. Asumsi ini menyamakan dua konsep, "Saya ingin mendapatkan file ini saat saya melakukan pembayaran." dan "Saya tertarik dengan perubahan file ini."

Sekarang, argumen dari kedua sisi dapat dirumuskan ulang seperti ini:

• "Saya ingin mendapatkan semua file yang dihasilkan ini saat saya melakukan pembayaran, karena saya tidak memiliki alat untuk membuatnya di mesin ini."
• "Saya tidak boleh memasukkannya ke VCS, karena saya tidak tertarik dengan perubahan file ini."

Untungnya, kedua persyaratan tersebut secara fundamental tidak saling bertentangan. Dengan beberapa ekstensi dari VCS saat ini, keduanya seharusnya dapat dimiliki. Dengan kata lain, ini adalah dilema yang salah. Jika kita merenungkan beberapa saat, tidak sulit untuk menyadari bahwa masalahnya berasal dari asumsi VCS berlaku. VCS harus membedakan file, yang dibuat oleh pengembang, dari file yang tidak dibuat oleh developer, tetapi kebetulan ada di dalam VCS ini. Untuk kategori file pertama, yang biasanya kami sebut file sumber (kode), VCS telah melakukan pekerjaan dengan baik sekarang. Untuk kategori yang terakhir, setahu saya VCS belum punya konsep seperti itu.

Ringkasan

Saya akan menggunakan git sebagai salah satu contoh untuk menggambarkan apa yang saya maksud.

• git status seharusnya tidak menampilkan file yang dihasilkan secara default.
• git commit harus menyertakan file yang dihasilkan sebagai snapshot.
• git diff seharusnya tidak menampilkan file yang dihasilkan secara default.

PS

Git hooks dapat digunakan sebagai solusi, tetapi akan lebih bagus jika git mendukungnya secara native. gitignoretidak memenuhi persyaratan kami, karena file yang diabaikan tidak akan masuk ke VCS.enter code here

Saya akan berdebat. Jika Anda menggunakan proses integrasi berkelanjutan yang memeriksa kode, mengubah nomor build, membangun perangkat lunak, lalu mengujinya, maka lebih sederhana dan lebih mudah untuk hanya memiliki kode itu sebagai bagian dari repositori Anda.

Selain itu, ini adalah bagian tak terpisahkan dari setiap "snapshot" yang Anda ambil dari repositori perangkat lunak Anda. Jika itu bagian dari perangkat lunak, maka itu harus menjadi bagian dari repositori.

Saya akan mengatakan bahwa ya Anda ingin meletakkannya di bawah kendali sumber. Dari sudut pandang manajemen konfigurasi, SEGALA SESUATU yang digunakan untuk menghasilkan software build perlu dikontrol agar dapat dibuat ulang. Saya memahami bahwa kode yang dihasilkan dapat dengan mudah dibuat ulang, tetapi argumen dapat dibuat bahwa itu tidak sama karena tanggal / stempel waktu akan berbeda antara dua build. Di beberapa bidang seperti pemerintah, mereka membutuhkan banyak waktu untuk melakukan apa yang dilakukan.

Secara umum, kode yang dihasilkan tidak perlu disimpan di kontrol sumber karena riwayat revisi kode ini dapat dilacak oleh riwayat revisi kode yang menghasilkannya!

Namun, sepertinya OP menggunakan kode yang dihasilkan sebagai lapisan akses data aplikasi alih-alih menulisnya secara manual. Dalam kasus ini, saya akan mengubah proses pembuatan, dan memasukkan kode ke kontrol sumber karena ini adalah komponen penting dari kode runtime. Ini juga menghilangkan ketergantungan pada alat pembuat kode dari proses pembangunan jika pengembang perlu menggunakan versi alat yang berbeda untuk cabang yang berbeda.

Tampaknya kode hanya perlu dibuat sekali, bukan setiap build. Ketika pengembang perlu menambah / menghapus / mengubah cara objek mengakses database, kode harus dibuat lagi, seperti membuat modifikasi manual. Ini mempercepat proses pembangunan, memungkinkan pengoptimalan manual dilakukan pada lapisan akses data, dan riwayat lapisan akses data dipertahankan dengan cara yang sederhana.

Saya (dengan menyesal) akhirnya meletakkan banyak sumber turunan di bawah kendali sumber karena saya bekerja dari jarak jauh dengan orang-orang yang tidak dapat diganggu untuk mengatur lingkungan bangunan yang tepat atau yang tidak memiliki keterampilan untuk mengaturnya sehingga sumber turunan dibuat dengan tepat. (Dan dalam hal Gnu autotools, saya sendiri adalah salah satu dari orang-orang itu! Saya tidak dapat bekerja dengan tiga sistem berbeda yang masing-masing bekerja dengan versi autotools yang berbeda — dan hanya versi itu.)

Kesulitan semacam ini mungkin lebih berlaku untuk proyek paruh waktu, sukarelawan, sumber terbuka daripada proyek berbayar di mana orang yang membayar tagihan dapat menuntut lingkungan pembuatan yang seragam.

Saat Anda melakukan ini, pada dasarnya Anda berkomitmen untuk membuat file turunan hanya di satu situs, atau hanya di situs yang dikonfigurasi dengan benar. Makefile Anda (atau apa pun) harus disiapkan untuk mengetahui di mana mereka berjalan dan harus menolak untuk mendapatkan kembali sumber kecuali mereka tahu mereka berjalan di situs build yang aman.

Jika itu adalah bagian dari kode sumber maka itu harus diletakkan di kendali sumber terlepas dari siapa atau apa yang membuatnya. Anda ingin kontrol sumber Anda mencerminkan status sistem Anda saat ini tanpa harus membuatnya kembali.

Benar-benar memiliki kode yang dihasilkan dalam kendali sumber, karena berbagai alasan. Saya mengulangi apa yang telah dikatakan banyak orang, tetapi beberapa alasan saya melakukannya adalah

1. Dengan file kode di kontrol sumber, Anda berpotensi dapat mengkompilasi kode tanpa menggunakan langkah pra-build Visual Studio Anda.
2. Saat Anda melakukan perbandingan penuh antara dua versi, alangkah baiknya mengetahui jika kode yang dihasilkan berubah di antara kedua tag tersebut, tanpa harus memeriksanya secara manual.
3. Jika pembuat kode itu sendiri berubah, Anda harus memastikan bahwa perubahan pada kode yang dihasilkan berubah dengan tepat. yaitu Jika generator Anda berubah, tetapi outputnya tidak seharusnya berubah, maka saat Anda memasukkan kode Anda, tidak akan ada perbedaan antara apa yang sebelumnya dibuat dan apa yang ada di kode yang dibuat sekarang.

Aku akan meninggalkan file yang dihasilkan keluar dari pohon sumber, tetapi meletakkannya di pohon membangun terpisah.

misalnya alur kerja

1. checkin / out / modifikasi / gabungkan sumber secara normal (tanpa file yang dihasilkan)
2. Pada kesempatan yang tepat, periksa pohon sumber menjadi pohon bangunan yang bersih
3. Setelah membangun, check in semua file "penting" (file sumber "asli", file yang dapat dijalankan + file sumber yang dihasilkan) yang harus ada untuk keperluan audit / pengaturan. Ini memberi Anda riwayat semua kode yang dihasilkan yang sesuai + executable + apa pun, pada penambahan waktu yang terkait dengan rilis / pengujian snapshot, dll. Dan dipisahkan dari pengembangan sehari-hari.

Mungkin ada cara yang baik di Subversion / Mercurial / Git / etc untuk mengikat sejarah file sumber sebenarnya di kedua tempat secara bersamaan.

Sepertinya ada pendapat yang sangat kuat dan meyakinkan di kedua sisi. Saya akan merekomendasikan membaca semua jawaban pilihan teratas, dan kemudian memutuskan argumen apa yang berlaku untuk kasus spesifik Anda.

PEMBARUAN: Saya menanyakan pertanyaan ini karena saya benar-benar yakin ada satu jawaban pasti. Melihat semua tanggapan, saya dapat mengatakan dengan tingkat kepastian yang tinggi, bahwa tidak ada jawaban seperti itu. Keputusan harus dibuat berdasarkan lebih dari satu parameter. Membaca jawaban lain dapat memberikan pedoman yang sangat baik untuk jenis pertanyaan yang harus Anda tanyakan pada diri Anda sendiri ketika harus memutuskan masalah ini.