Doximex.Com: [Sofware Engineering] - Subversion (SVN)

Friday, March 13, 2009

[Sofware Engineering] - Subversion (SVN) - 1

1. Tại sao cần Subversion

Tôi hiện có một chương trình face detector cho phép detect faces trong images (chuyện này OpenCV cũng làm được), và cho phép detect eyes trong detected faces (OpenCV ko có chức năng này). Chương trình này tôi viết từ hồi học PhD và sử dụng khá hiệu quả cho nhiều ứng dụng khác nhau. Tuy nhiên, do chương trình vẫn có một số bugs nên sau vài lần sửa, mỗi lần lưu một nơi khác nhau mà ko có chú thích gì; hậu quả là cho đến giờ, ngồi nhìn 5 copies của chương trình này, tôi ko biết ct nào là phiên bản cuối cùng ko còn bug nữa.

Đây là một ví dụ trong số rất nhiều ví dụ của tôi liên quan đến quản lí các phiên bản của chương trình trong quá trình lập trình. Cách làm thông thường là mỗi phiên bản lưu thành 1 thư mục. Sau đó, mỗi khi có project mới thì lại copy thư mục này sang thư mục của project mới, đồng thời vẫn giữ lại thư mục cũ để phòng khi có thể quay lại phiên bản cũ, nếu các cập nhật trong project mới bị lỗi. Làm tới, làm lui vài lần, cuối cùng ko biết mình sửa cái gì, ở đâu, khi nào. Đó cũng chính là lí do tôi cần có một cách quản lí hiệu quả hơn về các sự thay đổi trong quá trình tiến hóa của các code tôi viết. Các version control systems như subversion (svn) chính là giải pháp mà tôi cần tìm.

Version control is the art of managing changes to information. It has long been a critical tool for programmers, who typically spend their time making small changes to software and then undoing or checking some of those changes the next day. Imagine a team of such developers working concurrently - and perhaps even simultaneously on the very same files! - and you can see why a good system is needed to manage the potential chaos.

Có khá nhiều hệ thống hỗ trợ version control, ví dụ như cvs, subversion, git, etc. Ban đầu tôi chỉ biết cvs, nhưng sau đó mới biết thêm subversion, git. Sau khi tìm hiểu, tôi quyết định chọn subversion bởi vì subversion là "hậu duệ" của cvs, ra đời để khắc phục những hạn chế của cvs (hạn chế gì của cvs mà subversion có thể giải quyết, tôi chỉ mới nghe nói, ko hiểu gì vì chưa xài cvs và so sánh nó với subversion bao giờ!). Hiện nay subversion được sử dụng khá thông dụng trong rất nhiều dự án mã nguồn mở. Git mới ra đời gần đây, viết bởi tác giả của Linux. Trong bài nói chuyện của mình ở Google Talk, Linus chỉ trích subversion là sai về nguyên tắc cơ bản. Ý chính ở đây theo tôi hiểu đó là cách quản lí. Git của Linus dùng cơ chế phân tán (distributed), trong khi cvs và subversion dùng cơ chế tập trung (client/server). Tôi thì thích kiểu client/server hơn nên đã chọn subversion.

2. Một số khái niệm

Subversion dựa trên mô hình quản lí tập trung kiểu client/server. Mô hình này có 2 khái niệm cơ bản: Repository đặt ở server là nơi tập trung quản lí các phiên bản của các tập tin. Working Copies đặt ở client là các phiên bản làm việc của các tập tin trong repository. Repository thì chỉ có một, trong khi working copies có thể có nhiều (tương ứng với repository đó).

Một kịch bản thường thấy là các tập tin của project A được lưu ở repository. Sau đó, mỗi thành viên của project A, ví dụ P1, P2 sẽ checkout để lấy 1 phiên bản copy các file của project A này về máy cục bộ của mình (gọi là working copies). Mỗi khi P1 muốn các thay đổi trên các tập tin của project A ở máy cục bộ của mình cập nhật lên repository, anh ta sẽ dùng lệnh commit. Nếu P2 muốn thấy những thay đổi của P1 trên repository cập nhật xuống phiên bản đang dùng của mình, anh ta sẽ dùng lệnh update. Trường hợp P1 và P2 cùng cập nhật một tập tin, đây là vấn đề phức tạp nhất, và thao tác này gọi là merge. Subversion cung cấp các công cụ để nhận biết sự thay đổi của các tập tin ở working copies so với repository, đồng thời cũng cung cấp công cụ để giúp việc merge được dễ dàng.

Để quản lí các phiên bản khác nhau, subversion dùng khái niệm revision. Nói một cách đơn giản, để hệ thống có thể quản lí được sự thay đổi của các tập tin, mỗi tập tin sẽ có dạng Name-Revision. Ví dụ foo.c-rev1 và foo.c-rev2 là 2 revision của tập tin foo.c.

Cứ mỗi lần commit, toàn bộ repository sẽ có một con số revision mới (mỗi con số này là duy nhất và số của revision sau lớn hơn số của revision trước). Một điểm cần lưu ý là trong subversion, dù chỉ thay đổi một tập tin sau lệnh commit, nhưng toàn bộ các tập tin của repository sẽ có cùng một con số revision. Do đó, ko nhất thiết là foo.c-rev1 và foo.c-rev2 phải có nội dung khác nhau.

Thông thường, để có thể nhận biết được những thay đổi qua mỗi lần commit, người ta thường note lại những thay đổi này trước khi commit. Những note này sẽ được lưu vào history để sau này khi view lên có thể nhận biết được hiện trạng của từng revision, để khi muốn quay trở lại trạng thái trước đó cũng rất dễ dàng.

Một lưu ý rất căn bản đó là nếu bạn muốn subversion quản lí các phiên bản/thay đổi của một tập tin nào đó, thì mọi thao tác liên quan đến tập tin đó, ví dụ như xóa, sửa, tạo mới, etc đều phải thông qua subversion. Nói một cách khác, bạn nên tránh xóa một tập tin trong working copies bằng chức năng thông thường của file manager, ví dụ như dùng nút Del trong Explorer, thay vào đó nên dùng lệnh xóa của các subversion clients.

Tài liệu tham khảo
http://svnbook.red-bean.com/

(Còn tiếp)

Lê Đình Duy

Xem đầy đủ bài viết tại http://ledduy.blogspot.com/2009/03/sofware-engineering-subversion-svn-1.html