Saya akan membuat ini menjawab artikel blog karena itu pergi agak keluar topik GRIN. Pada http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ di bab 6 saya membuat beberapa penjelasan untuk SVN dalam gerhana tetapi Anda mungkin mencari sesuatu yang lain.
Kisah yang saya buat di sini adalah tentang komentar Anda
"Jadi untuk saat ini saya menggunakan fitur integrasi VCS di IDE (NetBeans, PHPStorm). Yang sering membuat saya bingung tentang hal spesifik dan cara melakukan sesuatu dengan benar." dan "Sesuatu yang berfokus pada konsep dan alur kerja, daripada mengetikkan garis-garis misterius di konsol."
Saya telah mendengar bahwa satu lagi saya ingin menjelaskan SVN dalam konteks yang lebih luas misalnya menggambarkan "bahasa pemrograman" terlebih dahulu dan kemudian menjelaskan PHP membuat Anda lebih memahami PHP dan dalam hal ini Manajemen Konfigurasi pertama dan kemudian solusi SVN di dalamnya.
Saya hanya akan mengetik sesuatu di sini dan jika di luar topik atau tidak diperlukan maka saya akan menghapusnya:
------------ 8 <----------------
Jika Anda menginstal Eclipse PDP, saya telah menulis ini: [ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
Jika Anda gulir ke bawah ke # 6 saya jelaskan secara singkat cara menginstal collabnet subclipse di Eclipse (pada dasarnya hanya arahkan ke server pilih semua dan instal)
Di Eclipse dengan alat manajemen versi apa pun, perintah untuk manajemen versi selalu berada di bawah klik kanan-kiri "TIM". Karena Anda dapat beralih antar proyek, Anda dapat memiliki dukungan untuk beberapa alat manajemen versi dan sebagian besar perintah sudah dikenal di atas alat melalui GUI.
Plugin
Seperti ANDA ketahui: Untuk proyek plugin WordPress baru Anda mendapatkan lokasi svn dari WordPress.org (di kotak surat Anda), mereka menggunakan Trunk untuk kode terbaru Anda dan salinan "tag" untuk rilis yang stabil. (Pola CM SANGAT dasar). Ini yang Anda lihat sekilas.
Jadi proyek Anda akan ditautkan ke TRUNK. dan Anda bisa berkomitmen untuk itu. Ini adalah tempat Anda bekerja (tetapi bukan tempat Anda merilis) (kecuali jika Anda menetapkan 'trunk' di readme.txt sebagai lokasi untuk kode akhir Anda).
Selanjutnya Anda dapat menyertakan WordPress / wp-include dan / wp-admin dalam proyek Eclipse Anda sebagai pustaka sehingga Anda dapat mencari fungsi dan melihat fungsi yang sudah tidak digunakan lagi. Ini tidak dapat ditulisi dan karenanya tidak berada di bawah manajemen versi (!). Ini dari sisi klien jadi bukan "eksternal" yang sebenarnya terhubung dalam proyek manajemen versi.
Segera setelah Anda memiliki versi stabil, pilih barang dan klik kanan "tim" dan "buat tag / cabang", ini membuka lokasi svn WordPress dan Anda dapat memilih direktori tag dan mengetik nomor baru dan versi baru Anda ditayangkan (yang mungkin berguna bagi seseorang yang membaca ini). Perhatikan bahwa Anda tidak boleh memilih root dari proyek Anda tetapi segala sesuatu yang lain atau itu akan membuat root juga di bawah tag Anda / 2.3.4 yang bukan apa yang Anda inginkan Anda ingin semuanya di bawah root berada di direktori / tag Anda.
Lihat posting untuk beberapa tangkapan layar.
http://wp.leau.co/files/2011/02/image_thumb17.png
Kontributor WordPress sendiri
Jika Anda seorang kontributor Anda dapat menggunakan yang sama seperti di atas tetapi Anda membuat "tambalan" dari perubahan yang Anda buat. "Patches" adalah sebuah konsep di dunia CM misalnya subversi menyediakan ini atau jazz RTC. Dengan klik kanan mouse "Terapkan tambalan" Anda dapat menerapkan tambalan jika Anda memiliki tambalan yang belum diterapkan ke batang WordPress.
Beberapa orang juga berkomitmen langsung ke bagasi.
WordPress sendiri "Baca"
Cukup buat proyek 'WordPress' yang berisi checkout versi / TERBARU di bagasi (dari kode subversi), sekali lagi, melalui tim> checkout.
Secara pribadi saya tidak melakukan ini tetapi hanya menggunakan ekspor kode terbaru (dengan paksa) untuk mendapatkan direktori dengan versi WordPress terbaru (sehingga tidak termasuk dalam manajemen versi apa pun)
Secara umum
Karena Anda memiliki pengalaman dengan VCS dan dengan pertanyaan seputar SVN: Pada dasarnya semua versi tooling adalah tentang konsep penamaan. Atau lebih baik dikatakan memiliki namespace terbaik. Anda dapat memetakan sebagian besar perintah dari CVS, Git, RTC, ClearCase, SourceSafe dll ... ke konsep di sekitar namespace ini. Karena Anda memiliki / sedikit pengalaman dengan alat lain, sedikit lebih luas:
Orang-orang baru sering menatap diri mereka buta pada perintah-perintah tertentu atau fungsi tertentu tetapi memberikan pilihan terbaik untuk menempatkan semua elemen yang dibutuhkan dalam namespace adalah hal inti.
Jadi karena ini pada dasarnya fungsi inti dari alat ini, istilah "manajemen versi" salah. Ini sebenarnya adalah nama-ruang-manajer.
Jadi kalau sudah
/ proyek A / departemen B / Tim C / Anggota D / Aliran E / Komponen F / Elemen G / Cabang H / Cabang I / Versi J
Anda dapat membuat nama unik untuk setiap "hal". Di atas adalah implementasi namespace yang Anda butuhkan untuk tujuan tertentu menggunakan salah satu alat namespace.
Hampir semua konsep di dunia ini dapat dipetakan ke sini sehingga cara Anda BISA mendukung ruang nama kustom / taksonomi Anda tergantung pada kemampuan alat Anda. Jadi ... itu benar-benar tergantung pada konsep dan pilihan para perancang dari ratusan alat berbeda yang telah dibuat.
Dalam alat yang baik Anda dapat mengklik dan melihat taksonomi lengkap ini dalam satu pohon atau memperbesar satu pohon itu.
Itulah intinya: alat yang dapat membantu Anda mengelola kompleksitas (lihat kompleksitas di wikipedia: http://en.wikipedia.org/wiki/Complexity ) dengan memberi Anda alat yang baik untuk mengelola taksonomi KUSTOMA ANDA. Orang yang membuat taksonomi yang berpikir bagaimana mengaturnya adalah manajer konfigurasi yang ia tulis rencana yang disebut rencana manajemen konfigurasi yang memikirkan hal ini terlebih dahulu.
Bayangkan saja seseorang meminta Anda untuk membuat satu set taksonomi khusus di WordPress yang mewakili SEMUA objek di perusahaannya termasuk kemampuan untuk mengeluarkan keadaan seperti itu pada saat tertentu. Anda dapat membuat banyak pilihan desain dan semua orang akan menghasilkan sesuatu yang lain berdasarkan beberapa pilihan. Beberapa akan mengandung lebih banyak fitur beberapa lebih sederhana dan yang lebih kompleks semua membuat keputusan yang berbeda. Ini adalah "alat-alat ini". Jadi saya tidak pernah mengerti diskusi tentang tingkat alat tentang manajemen versi karena itu benar-benar aneh.
Dalam PHP saat ini Anda dapat membuat ruang nama Anda membuat hierarki dengan direktori, menerapkan konvensi penamaan untuk objek dan di dalamnya metode. Jika Anda mengambil satu file yang telah Anda tempatkan dalam hierarki, ambil satu langkah lebih jauh. Anda menambahkan satu / di belakangnya dan menempatkan nomor versi di belakangnya. Itu bahkan tidak cukup karena Anda ingin tim A bekerja pada versi 4 file dan tim B bekerja pada versi itu. Jadi, Anda menambahkan / dan menambahkan id cabang. Ini adalah bagaimana Anda membangun namespace. Bergantung pada alatnya, Anda bisa menjadi gila seperti yang Anda inginkan.
Tetapi itu berarti: jika seseorang datang kepada Anda bertanya "di mana dokumen Z" Anda tidak bisa memberikan jawabannya. Karena dalam sistem manajemen versi "dokumen Z" tidak ada. Dan bahkan ketika dia mengatakan memberi saya "dokumen Z versi 5" Anda tidak bisa menyerahkannya karena dia bisa berarti "mendokumentasikan Z versi 5" dari cabang 1 tim atau "dokumen Z versi 5" dari cabang 2 tim. Ini semua tentang penamaan. "dokumen Z versi 5" hanyalah pendekatan penamaan yang tidak benar di ruang nama yang ditentukan.
Di Subversion Anda hanya dapat melakukan ini terbatas, sehingga membuatnya mudah dimengerti. Beberapa konsep cocok dengan ini:
"Versi: kapan"
Versi adalah revisi dari elemen tertentu. Jadi misalnya wp-config.php versi 5. Dalam alat seperti ClearCase Anda juga dapat melihat versi individual elemen dan "mengkomit" file individual (tetapi juga melakukan atomik atau mengubah set atau apa pun).
Dalam versi penanganan Subversion lebih terbatas:
- satu set perubahan yang Anda buat secara lokal dalam sekali jalan Anda " komit " yang berarti bahwa set lengkap "perubahan" secara atomik dilakukan dan seluruh basis mendapatkan nomor versi baru. Ini adalah nomor versi yang Anda lihat di situs subversi WordPress.
- jadi Anda tidak dapat membuat lebih banyak perubahan secara lokal pada 1 file dan semuanya diperlakukan sebagai versi baru tunggal seperti pada clearcase. semua perubahan yang Anda buat secara lokal untuk 1 file atau yang lain dikirimkan dalam sekali jalan dan dapatkan "nama baru yang unik".
- jika Anda tidak memiliki akses ke repositori (hak) Anda dapat membuat satu set perubahan dan menyimpannya dalam "tambalan". Anda kemudian dapat mengirim tambalan itu kepada seseorang seperti manajer integrasi atau bahkan manajer build yang menerapkannya ke repositori. Alat seperti misalnya RTC juga mendukung "tambalan". Jadi satu orang membuat tambalan dan yang lainnya menerapkan tambalan. Anda harus mempertimbangkan ini benar-benar sebagai kata yang berarti "tambalan" jadi bukan kasus penggunaan default pengembangan kode.
- selain / branch N / hello.doc / versi 25 ada juga label seperti / branch N / hello.doc / TERBARU atau / KEPALA. Dalam beberapa sistem manajemen versi, Anda dapat menerapkan label yang kompleks dan kemudian menulis skrip yang bekerja pada label ini.
mengerjakan versi
Dalam Subversion, use case default adalah Anda cukup mengunduh semua hal ke harddisk Anda dari kasir repositori , mengerjakannya, lalu komit dan kemudian menghadapi semua perubahan yang dilakukan orang lain setelah Anda menyelesaikan konflik. Konsep-konsep ini Anda lihat di GUI. JIKA Anda ingin mencegah orang lain juga mengedit misalnya Anda hello.doc maka Anda LOCK artinya: tidak ada orang lain yang dapat mengubahnya.
SAYA BENAR-BENAR tidak suka ide itu :( IMHO itu praktik yang sangat buruk. Untuk perbandingan dan pemahaman: Di ClearCase checkout lebih atau kurang sebanding dengan kunci dan checkin adalah komit (dalam checkin subversi adalah alias untuk komit) Ini adalah kasus penggunaan default di ClearCase di mana ia juga mendukung pembajakan yang sama dengan checkout subversi tetapi kemudian pada file yang dipilih. IMHO ini jauh lebih bersih. Lebih lanjut bahkan ketika Anda melakukan checkout di ClearCase itu memberi Anda 3 pilihan: lainnya orang tidak dapat mengerjakannya (mis. dengan kata docs), orang lain dapat mengerjakannya jika benar-benar diperlukan dan "semua orang dapat mengerjakannya" (mis. dengan file kode sumber) Jadi ... inilah yang dimaksud checkout, kunci, dan komit dalam SVN.
komponen dan baselining
Dalam alat seperti RTC dan ClearCase Anda dapat mengelompokkan elemen menjadi komponen. Kuat karena komponen-komponen ini adalah bagian dari ruang-nama dan mendapatkan versi mereka sendiri dengan mendasarkannya. Jadi misal komponen "WordPress" mendapat rilis awal 4.53. Baseline ini kemudian objek dalam diri mereka sendiri yang kemudian juga bisa mendapatkan metadata seperti "dalam tes". Namun SVN tidak memiliki APA SAJA ini. Jadi ...:
tag
Di SVN (dan seterusnya di situs WordPress) Anda melihat direktori dengan angka di direktori keseluruhan yang disebut 'tag'. Ide solusi. Anda cukup mengambil repositori tertentu dan membuangnya (berbasis file) ke dalam tag direktori / 3.2.4. Itu dia. Ini tidak memiliki hubungan dalam namespace manajemen versi dll ... hanya direktori sederhana .... HARI ..... Impossible IMHO untuk melakukan manajemen konfigurasi dengan alat semacam ini. Jadi itu bukan objek metadata di mana Anda dapat skrip melawan dan menetapkan properti dan melakukan hal-hal terliar tidak ... hanya direktori ............. Dalam RTC untuk perbandingan, Anda dapat membuat ' snapshot 'dari baseline tertentu untuk juga mendukung use case ini. Di ClearCase UCM Anda akan membuat cabang / aliran baru dari baseline tertentu dan kemudian 'melihatnya'.
ranting
Ini tidak digunakan di lingkungan WordPress sejauh yang saya tahu, tetapi mungkin saya salah dan ada tim yang melakukan ini untuk rilis WordPress untuk mendukung perubahan port ke versi yang lebih lama. Jadi saya tidak tahu, mungkin orang lain tahu.
Ini digunakan untuk pohon namespace. Untuk membuat 2 tim mengerjakan kode yang sama Anda bisa mengatakan "dalam bahasa Inggris" \ team 1 \ hello.doc dan \ team 2 \ hello.doc. Kedua tim kemudian mulai bekerja dan setelah beberapa saat Anda memiliki \ team 1 \ hello.doc \ versi 51 dan \ team 2 \ hello.doc \ versi 23. (jadi tim 1 membuat 51 versi dan tim 2 membuat 23 versi). Sekarang Anda memiliki kemungkinan untuk bergabung dari tim cabang 1 ke tim cabang 2 dan Anda akan mendapatkan gabungan di tim 2 tetapi pada akhirnya tim 2 akan memiliki semua perubahan tim 1 (versi 24) dan masing-masing cabang masih menunjukkan pekerjaan untuk masing-masing dari mereka.
Dalam RTC dan ClearCase ini tidak digunakan tetapi objek yang lebih maju yang disebut "stream" (untuk perbandingan). Dari perspektif yang rendah Anda dapat menganggap ini TETAPI yang sama ....... ketika Anda berada di kehidupan nyata cabang Anda akan mengandung BANYAK hal. Jadi di dunia nyata Anda harus membuat catatan, melepaskan catatan, dokumentasi dll ... Untuk meningkatkan ini, aliran tidak hanya berisi "kode" tetapi juga "perubahan" sehingga Anda tahu bahwa RFC23 tentang versi 34,32 dan 56 dan Anda dapat melepaskannya secara terpisah.
IMHO jika Anda ingin mengatur hal-hal yang benar maka Anda memberi SETIAP orang satu atau lebih aliran / cabang pribadi. Sehingga mereka dapat checkin / melakukan dan checkout dari sana dan itu mengganggu siapa pun. hanya ketika seseorang siap mereka "mengirimkan" barang-barang mereka ke misalnya aliran tim dan aliran tim memberikan ke aliran integrasi dll ... Di WP mungkin rilis adalah cabang tetapi untuk orang-orang biasa: mereka semua bekerja di cabang yang sama. Kerugian karena "proyek pengujian" kemudian dalam c: \ temp dan tidak di bawah manajemen versi dan Anda tidak dapat memiliki sekelompok orang sementara bekerja pada fitur X yang hanya akan diperlukan dalam 5 waktu rilis.
dunia dan pertukaran yang ideal
jika Anda memiliki \ team1 \ hello.doc dan seseorang menyalin di \ team2 \ JUGA hello.doc bahwa ini adalah BAaaaaad. Karena sekarang kami memiliki 2 elemen dengan ID berbeda di mana pengguna berpikir mereka sama tetapi sistem memperlakukan mereka sebagai tidak sama. Ini disebut 'si kembar jahat' dan Anda tidak boleh melakukan ini di lingkungan seperti itu. Selalu gabungkan atau pangkalan cabang. Jika Anda memahami kembar jahat, Anda memahami cabang (mengapa ini buruk: karena pada suatu penggabungan mereka akan diperlakukan sebagai 2 entitas yang berbeda sementara Anda ingin mereka diperlakukan sama) (atau jenis perilaku yang berbeda dalam sistem yang berbeda). Jika pengguna baru mengacaukan segalanya, ini sebagian besar adalah masalah itu. 'Saya baru saja menghapus hello.doc dan menyalinnya kembali di' argh
PERUBAHAN
SVN tidak menawarkan dukungan untuk NAMUN ini, tetapi ada alat yang dapat Anda integrasikan dengannya untuk mendukung semacam manajemen perubahan terpadu / ALM. Dalam alat-alat seperti varian ClearCase- UCM atau RTC Anda tidak dapat mengubah 1 huruf tanpa ada cacat, RFC, tiket, dll ... Di SVN ketika Anda komitAnda dapat mengetik deskripsi untuk komit atom Anda. Artinya: Anda harus mencoba membuat Anda mengubah bagian-bagian "yang dapat ditambal" dengan kata lain: lakukan komit atom per cacat / perubahan agar memiliki perilaku seperti itu. (Tapi tentu saja tidak setelah itu semua terhubung bersama di pohon penamaan seperti dalam database ClearCase) (sehingga Anda dapat mengotomatiskan catatan rilis atau membantu orang miskin menjadi manajer penyebaran mendapatkan banyak kode baru, perubahan, rilis dan mencoba untuk berbaur bersama-sama tanpa alat nyata untuk memberinya wawasan tentang apa itu sebenarnya).
Karena SVN tidak mendukung manajemen perubahan, WordPress mengatur untuk menggunakan TRAC: http://core.trac.wordpress.org/ seperti yang Anda tahu karena Anda tinggal di sana :)
Saya rasa TRAC ada di sana karena alat nyata seperti ClearCase atau RTC yang memiliki perubahan terintegrasi sebagai objek (ya yang Anda program melawan) hilang. Jadi Anda memiliki alat di mana Anda mendiskusikan dan mengirimkan perubahan "semacam" yang diatur ke (sementara konsep itu juga hilang). Jadi ini adalah "tambalan" hanya sekelompok file tanpa metadata yang Anda harapkan dalam sistem yang baik (jadi saya sekarang dalam keadaan galak). Jumlah TRAC penting karena itu adalah ID keseluruhan di pohon penamaan yang dikaitkan dengan beberapa perubahan.
Memberikan Perubahan
Ini adalah sesuatu untuk ditulis dalam artikel blog terpisah. Singkatnya: di dunia ideal Anda ingin memilih perubahan yang ingin Anda 'tayangkan' (atau konsep lain) dan kemudian jangan khawatir tentang file, direktori (versi). Anda hanya "mengirimkan RFC 3 dan 5". Ini adalah cara kerja ClearCase UCM atau RTC. Di SVN / base clearcase Anda 'melakukan' banyak file di mana kami berharap Anda membuat keputusan yang tepat. Itu adalah perbedaan besar dan penting. (inilah sebabnya sebagian besar SVN digunakan bersama-sama terintegrasi dengan misalnya jira / clearquest / etc ... untuk mencapai perilaku ini). Patching .... tidak memberikannya lebih dari 1 streaming ke yang lain sebagai 'patch' uhm.
Eksternal
Dalam alat lain Anda ini berbeda dalam SVN itu lebih sederhana: jika Anda memiliki kode dari bagian yang bukan milik Anda maka Anda dapat memperlakukannya sebagai versi eksternal yang dikelola dan ... untuk kembali ke konsep inti: maksud Anda bahwa bagian tidak termasuk dalam tanggung jawab ruang nama Anda karena ini semua tentang penamaan. TETAPI meskipun itu eksternal, itu menjadi tanggung jawab Anda.
Dalam GUI tidak ada alur kerja dalam "mouse kanan" biasa tetapi didefinisikan dalam struktur proyek. Jadi itu adalah bagian dari definisi Anda.
Konsep ini, jika digunakan, didefinisikan dalam IEEE CMP sebagaimana diminta untuk didefinisikan (Lihat di bawah)
Integrasi dan Penggabungan
Seperti Yang Dikatakan. Paradigma di balik SVN adalah untuk mendapatkan barang secara lokal, melakukan pekerjaan Anda dan kemudian melakukan dan kemudian melakukan s **** s. Di GUI Anda mendapatkan alat meskipun persis sama seperti kebanyakan orang lain. Di sini Anda harus benar-benar memahami penggabungan tiga arah, penggabungan dua arah dan perbedaan antara konflik yang dapat diselesaikan secara otomatis dan konflik yang tidak dapat diselesaikan secara otomatis. Yang terakhir ini kemudian jatuh ke dalam 2 kelas: kelas-kelas di mana alat ini dapat mengusulkan Anda apa hasil akhir yang baik dan mereka yang tidak tahu apa akhirnya. Anda bertanya tentang GUI tetapi pada baris perintah Anda mendapatkan file informasi tentang apa yang harus Anda perbaiki / gabungkan sebelum melakukan.
Banyak lagi untuk artikel blog. (mis. Pengembangan Sumber Terbuka versus Pengembangan Perusahaan dan membangun manajer dan manajer integrasi karena Anda benar-benar harus membuat pilihan yang berbeda di sini).
Terakhir, CMP
Apa yang Anda minta adalah Rencana Manajemen Konfigurasi untuk WordPress. Ini adalah dokumen IEEE. Artinya: apa pun dari jutaan paket manajemen konfigurasi yang Anda temukan di Google, semuanya valid terhadap IEEE yang ditentukan (beberapa versi) CMP.
Sama seperti (misalnya HTTP) RFC ada IEEE CMP.
Paket ini berisi bagian-bagian tertentu seperti "bagaimana memperlakukan eksternal" dan "bagaimana namespace terlihat, bagaimana kita mengambil item dan bagaimana kita mereproduksi item", peran, tanggung jawab dll ...
Dari CMP ini Anda kemudian dapat membuat instruksi kerja. Siapa pun yang ingin tahu aturannya dapat membaca CMP.
Dalam konteks open source seringkali peran 'manajer konfigurasi' tidak ada. Jadi, Anda juga melewatkan Rencana Manajemen Konfigurasi.
Berbeda dengan RFC publik (mis. URI atau HTTP) Anda harus membayar untuk dokumen standar IEEE tetapi ... jika Anda Google, Anda akan menemukannya di sana-sini.
Jalan Pengiriman
Di jalan pengiriman Anda akan memiliki tim yang memikirkan ide bisnis baru. Anda memiliki departemen pemeliharaan yang mendapatkan bug produksi trilyun di sistem mereka. Anda akan meminta banyak tim mengerjakan kode yang sama. dan di setiap substreet Anda akan memiliki tim persyaratan yang menentukan persyaratan. Tim arsitektur dibagi dalam tim fungsional dan tim operasional (kasus penggunaan pergi ke tim fungsional dan non fungsional ke tim operasional). Anda akan sering memiliki rilis paralel yang berbeda secara langsung di lingkungan pengujian unit, lingkungan penerimaan, lingkungan pengujian beban dan stres, lingkungan pengujian fungsional, lingkungan pengujian pra produksi dan lingkungan produksi.
Dalam semua dari mereka adalah versi yang semuanya dilacak satu sama lain.
satu versi pada lingkungan pengujian tertentu ditautkan ke satu set versi yang ditautkan ke RFC tertentu dan yang satu ini ditautkan ke versi persyaratan tertentu. Persyaratan tersebut kemudian ditautkan ke versi testset tertentu. SEMUA berada di bawah manajemen versi.
Dalam WP dengan SVN / TRAC saya belum menemukan database persyaratan dan database versi persyaratan. (sehingga Anda dapat melakukan analisis dampak dan melihat kode apa yang berubah jika Anda mengubah 1 persyaratan) (dan bahwa dalam rilis baru Anda dapat mencetak persyaratan mana yang telah berubah). Saya telah melihat item individual di TRAC di mana tautan dibuat ke item individual lainnya di TRAC dalam komentar. Saya juga belum melihat keterlacakan antara item TRAC dan kode selain di komentar. Jadi itu berarti orang melakukan banyak hal di kepala mereka dan itu sangat tergantung pada komunitas aktif atau pengembang inti karena mereka memiliki banyak hal di otak mereka.
Tapi ini menyeringai jauh dari topik
OSLC untuk ALM
Hanya satu catatan lagi untuk cerita ini: tidakkah menyenangkan jika akan ada satu paket standar untuk semua alat manajemen siklus hidup aplikasi (ALM) ini? Seseorang memikirkan hal itu dan sekarang ada standar sehingga semua konsep ditempatkan pada tingkat abstraksi yang lebih tinggi dan kemudian diimplementasikan dalam perangkat. Google: OSLC untuk ALM. (sehingga semua alat dapat berbicara satu sama lain dan untuk pengguna: bahwa Anda memahami semuanya dengan memahami lapisan abstraksi).
TENANG
Bahkan satu langkah lebih jauh jika Anda punya waktu: dunia sekarang menuju C / ALM, produk generasi berikutnya di mana proses dan peralatannya adalah satu hal yang terintegrasi sehingga Anda tidak perlu bertanya-tanya lagi apa prosesnya. Produk pertama dalam generasi ini adalah RTC. Jadi jika Anda memahami SVN dengan baik atau memahami ClearCase atau Jira atau Trac atau ANT atau Agile atau RUP atau iRUP atau proses apa pun, manajemen versi, manajemen perubahan, hal manajemen pembangunan, Anda akan memerlukan semua itu untuk memahami RTC karena semua itu digabungkan dalam satu hal karena mereka semua mengikat bersama dan ini dengan sendirinya adalah antarmuka melalui OSLC sehingga salah satu alat yang lebih tua ini bisa "pasang".
Tapi sekarang saya benar-benar di luar topik.