Beranda > Uncategorized > Change to anything but Subversion

Change to anything but Subversion

Menurut pendapat saya, dalam pengembangan software yang besar dan kompleks penggunaan version control software untuk memelihara source code yang mencapai ribuan baris adalah mutlak dilakukan. Manusia memiliki kemampuan mengingat yang sangat terbatas. Apakah Anda mampu mengingat apa yang Anda lakukan pada hari dan jam ini di minggu kemarin? bulan kemarin? tahun kemarin?

Subversion telah banyak membantu saya dalam menemukan sumber permasalahan dengan cepat dan akurat, berkoordinasi dengan rekan programmer dalam satu tim, dan masih banyak lagi. Subversion dapat diintegrasikan dengan bug tracking software untuk meyakinkan bahwa tidak ada permsalahan yang belum ditangani sebelum final release. Subversion berbeda dengan CVS (Concurrent Versioning System) dalam hal rollback terhadap versi yang telah di-commit. Sehingga dituntut keterbukaan, kejujuran, dan tanggung jawab. Adalah suatu hal yang wajar bila muncul konflik akibat dapat diketahui dengan jelas, cepat dan menyakinkan siapa yang melakukan kesalahan. Tunjuk menunjuk siapa yang melakukan kesalahan adalah hal berikutnya yang dapat diperkirakan dengan mudah. Namun anehnya, hal ini jarang terjadi kerena kemampuan memaafkan, persahabatan dan kerja sama tim programmer yang kuat (ditambah dengan kenyataan bahwa standar gaji programmer di Indonesia sangat jauh dengan luar negeri, oleh karena itu saya dapat memahami perasaan para pembuat virus di Indonesia, keep the fighting spirit, guys !!!). Dan paling-paling akibat yang diterima adalah tidak diajak dalam project berikutnya.

Dalam beberapa kali diskusi, disimpulkan bahwa sejalan dengan kompleksitas project yang ditangani penggunaan subversion tidak dipandang sebagai suatu alternatif yang layak dipertimbangkan. Dan kami sepakat, there is something wrong with this picture!

Permasalahan pertama, ketika kita melakukan commit ke trunk, source code yang berada di dalamnya otomatis akan diterima oleh programmer lain. Dan apakah source code yang Anda kirimkan telah Anda buat dengan sempurna? Kalau Anda menjawab “Ya” berarti Anda mengingkari hati nurani Anda. Source code yang Anda kirimkan kemungkinan memiliki bug karena belum melalui proses testing! Dan sekali source code ini di commit ke trunk maka dapat menjadi masalah yang besar untuk dapat menjadikannya lagi sebuah versi stabil.

Masalah berikutnya dalam penggunaan subversion adalah merging. Kita terbiasa untuk membuat braches baru untuk mengembangkan fitur baru, memperbaiki bug atau uji coba penerapan metode baru yang diharapkan akan menambah performance atau flexibititas dari software yang dikembangkan. Selain itu, kita tidak mengotori trunk yang kita anggap sebagai versi stabil. Masalah timbul saat kita harus melakukan merge dengan trunk. Apalagi kita harus melakukan merge untuk lebih dari satu branch. Yang pasti hal ini bisa bikin mabok. Menurut pengalaman, pekerjaan ini dapat memakan waktu lebih dari satu hari kerja ! cape dech ..

Dan satu permasalahan yang masih dalam ingatan saya adalah kebutuhan untuk melakukan commit dalam hal programmer tidak berada dalam satu network dengan subversion server atau dalam satu network namun dengan akses yang lambat. Hal ini dapat diperburuk dengan implementasi SSL di subversion server dengan alasan keamanan. Kebutuhan ini timbul akibat perlunya mencatat perbaikan terhadap satu bug di antara banyak bug yang ditangani. Diharapkan dari pencatatan perbaikan ini, perbaikan terhadap seluruh bug yang dikerjakan akan mudah dilacak dan dianalisa.

Salah satu alternatif pemecahan masalah di atas adalah menggunakan konsep distributed revision control. Hal ini berbeda dengan subversion yang menganut centralized revision control. Dan apabila dimungkinkan software yang baru mendukung konversi dari subversion. Saya belum dapat memberikan pendapat perihal distributed revision control software yang bagus. Namun, beberapa alternatif software yang telah saya coba, antara lain:

  1. Bazaar. Telah diikuti petunjuk install namun mengalami kesulitan dalam menggunakan GUI nya.
  2. Fossil. Hanya terdiri dari satu file executable, menggunakan database SQLite, memiliki fitur web interface, integrated ticketing system. Menurut dokumentasi kecepatanya dapat diandalkan, namun saya belum mencoba dengan source code yang memiliki ribuan atau ratusan ribu baris.
  3. Git. Dikembangkan oleh Linus Torvalds, penemu sistem operasi linux yang panjang umur karena jasanya pada dunia open source. Saya telah mencaba versi command line namun belum menemukan versi GUI.
  4. Mercurial. Memiliki portable version. Sebagian besar operasi yang dilakukan masih menggunakan command line.

Dari beberapa software yang telah dicoba, saya belum dapat menggunakannya dengan baik sebagaimana subversion. Mungkin benar apa yang dikatakan Joel Spolsky dalam tutorialnya yang mengatakan bahwa agak susah untuk memahami konsep distributed revision control terutama bagi mereka yang telah akrab dengan subversion.

Kategori:Uncategorized
  1. April 5, 2010 pukul 16:03

    Apakah Subdit Pengembangan Aplikasi DSP sudah mengakui dan menggunakan subversion ini ? Atau setidaknya SP2D? Mudah2an aja ke depan semua software yang dikembangkan punya standar revisi, sehingga tidak asal ngasih nama revisi.

    • cakyus
      April 5, 2010 pukul 16:19

      mengakui atau tidak itu terserah, penggunaan subversion sendiri lebih ke arah kemudahan programmer dan system analys. terutama untuk menelusuri jejak, atau riwayat dari source code. masalah nama revisi, memang belum ada peraturan yang mengatur. namun, bila menggunakan versioning, kita bisa tahu dengan pasti dan yakin keseluruhan source code pada versi tertentu. terutama bila ada update yang ternyata update yang baru malah ada fitur yang nggak berfungsi sebagaimana mestinya. tanpa versioning, kita harus mikir lagi.. kalo pake versioning, tinggal dikembalikan ke versi sebelumnya atau dianalisa dengan membandingkan versi sekarang dan versi sebelumnya. semoga bermanfaat.

    • cakyus
      April 6, 2010 pukul 17:49

      perihal versi, versi di aplikasi sp2d (dulu, nggak tau sekarang) berformat Major.Minor.Revision .. angka di major berubah bila ada perubahan besar2an atau perubahan yang bersifat mendasar eg. perubahan database, yang mengakibatkan semua form tidak bisa diyakini kebenarannya .. perubahan pada minor mencerminkan ada fitur yang ditambah atau dikurang eg. tambah karwas up .. angka revision HARUS sama dengan angka revision pada server subversion, hal ini untuk menyamakan pemahaman terhadap versi source code yang tengah dibicarakan .. seringkali permasalahan selesai dengan super cepat dengan hanya mengetahui versi yang digunakan

  2. iamjek
    April 8, 2010 pukul 16:50

    menarik sekali ulasannya cak yus, selama ini saya belum pernah mencoba, kalo bisa tutorialnya di tulis sekalian, trism

  1. No trackbacks yet.

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: