Architecture and Design of Subversion - SVN (Part 1) (Vietnamese)

Architecture and Design of Subversion - SVN (Part 1) (Vietnamese)

Chào các bạn, hôm nay mình không rảnh lắm, cơ mà mình đang tìm hiểu về thứ của nợ này nên tiện tay viết một bài tổng hợp kiến thức vậy.

Thứ mà chúng ta sẽ nghía qua hôm nay là: Subversion – hay còn được gọi là SVN – một hệ thống quản lý mã nguồn theo phiên bản: Revision Control hay Version Control hay Source Control thì cũng là nó. Trong bài này mình sẽ sử dụng khái niệm Version Control và SVN.

Khái niệm trước

Version Control là một khái niệm trong Software Configuration Management, chỉ việc quản lý hệ thống dữ liệu bằng cách đánh chỉ mục các thay đổi dưới dạng số (như SVN) hay chuỗi kí tự (Git), chỉ mục này được gọi là revision number hay revision level hoặc revision.

Đại khái là: project của mình có 1 file tên là TestNetwork.java, lần đầu code nó có mỗi 1 hàm main với vài dòng sysout vớ vẩn, khi đưa lên version control, mình sẽ có revision 1.

Sau đó mình bắt đầu thêm vài dòng vớ vẩn khác như là int x = 6; x += 5; blah blah và đưa lên version control lần thứ 2, mình sẽ có revision 2.

Đặc điểm của các hệ thống version control là, chúng ta có thể làm việc với bất kì revision nào. Nói cách khác, ta có thể có được nội dung của revision 1, 2 hay 1000 mà không cần phải Ctrl-Z hay vò đầu nhớ xem hôm qua mình đã code cái gì. Đồng thời cũng biết mấy thằng của nợ cùng team nó vừa sửa đểu gì trong code của mình. Khá là hấp dẫn phải không nhỉ?

Như thế, ta hiểu rằng: mục tiêu của Version Control là kiểm soát và theo dõi sự thay đổi của dữ liệu trong project, dữ liệu đó có thể ở rất nhiều dạng: code, database, schema, documentation, asset, configuration, binary, multimedia,…

Subversion

Subversion, là một Version Control System, free, open source, được bảo kê bởi CollabNet, đại gia Apache và được xài trong rất nhiều các hệ thống và dự án lớn, một vài cái tên be bé là: Apache Software Foundation, KDE, GNOME, Free Pascal, FreeBSD, GCC, Python, Django, Ruby hay Mono.

Subversion có kiến trúc như sau:

![ch01dia1](https://coch01dia1

Nhìn qua hình, ta thấy về cơ bản, subversion sẽ có một Repository đóng vai trò làm server chứa dữ liệu, cung cấp giao thức cho phía client sử dụng giao thức tương tự. Client sẽ sử dụng giao diện GUI hay CLI tùy ý, thông qua thư viện Subversion để gửi và nhận dữ liệu.

Cấu trúc của Subversion thường được chia thành 3 folder chính, dĩ nhiên ta có thể thêm bớt tùy ý nhưng hầu hết các project lớn đều dùng cấu trúc này:

  • Thư mục trunk: chứa code mới nhất theo đúng nghĩa đen, vì vậy đây thường là code dang dở, đang trong quá trình phát triển của dự án.
  • Thư mục tags: thường chứa snapshot khi cần release cho dự án. Lấy ví dụ, Project A release tại version 1.0, toàn bộ code tại trunk sẽ được tạo thành tag 1.0 tại thời điểm đó, và như thế, khi cần build hoặc deploy hay review lại phiên bản 1.0 của project, ta chỉ cần lấy tag 1.0 về là xong, tương tự với các tag khác.
  • Thư mục branches: như tên gọi, chứa các nhánh phát triển của dự án. Project A có thể song song phát triển tính năng X và tính năng Y mà không ảnh hưởng đến nhau, ta gọi đó là 2 branch của SVN, khi cần gộp lại cho official release, các branch có thể được gộp lại.

Cho hình cho sinh động:

[500px-Revision_contr500px-Revision_controlled_project_visualization-2010-24-02.svg_

Cái hình nho nhỏ này biểu diễn trạng thái phát triển của 1 SVN, cùng với 1 số action đặc trưng của Version Control System.

  1. Thư mục Trunks của SVN
  2. Từ thư mục Trunks, project tạo ra Branch mới cho việc phát triển
  3. Làm việc với Branch mới
  4. Khi Branch mới đã hoàn thành feature, tiến hành gộp lại với branch chính, quá trình này gọi là Merge
    T1: tại đây, project đã stable và được tag lại thành T1
    5, 6: Tiếp tục tạo ra các branch mới cho feature độc lập
    8: Branch mới được phát triển
    10: Branch này bị dừng phát triển, development sẽ bị deactive từ đây và không còn ai làm việc trên branch này nữa
    6, 7: Branch mới được phát triển
    9: Branch mới hoàn thành feature, tiến hành Merge vào branch chính
    T2: project hoàn thành feature của giai đoạn tiếp theo, tạo ra tag T2 để lưu lại

Một số khái niệm chính trong SVN

  • reposiroty: server chứa SVN và đặt project
  • HEAD: đỉnh của cấu trúc SVN
  • master: thông thường khi tạo SVN, có một branch chính được tạo ra và gọi là master, các branch phụ thường được đặt theo tên feature mà branch đó được tạo. Với hình trên, đường nối các ô màu xanh lá thể hiện master, các đường nối ô màu vàng thể hiện branch được tạo ra
  • change: mô tả sự thay đổi cụ thể của 1 revision so với revision trước đó
  • working copy: bản copy của toàn bộ SVN tại máy của developer
  • conflict: xung đột xảy ra khi có nhiều developer cùng làm việc với 1 working copy, VD A và B cùng checkout rev 40 của file config.js, sau đó A sửa function update() rồi commit lên rev 41, lúc này B cũng sửa function đó, khi B checkout về sẽ xảy ra conflict do SVN không biết được phiên bản của A hay B mới là latest
  • resolve: lúc này, B sẽ xem xét lại code trong function, giữ lại đoạn code của A hoặc sửa nó, đánh dấu conflict đã được resolve

Một số action quan trọng khi sử dụng và triển khai SVN

  • commit: khi developer tiến hành thay đổi code, architecture, structure, documentation,… và đưa nó lên server SVN, việc này được gọi là commit, các commit sẽ buộc phải kèm theo message mô tả đầy đủ sự thay đổi của lần commit đó, mỗi commit sẽ tăng số revision của SVN lên 1
  • checkout: user với credential truy cập vào SVN và lấy nội dung của SVN tại 1 revision nhất định về, thông thường có thể là revision mới nhất, revision này sẽ được gọi là HEAD – đỉnh của cấu trúc SVN
  • revert: sau khi tiến hành thay đổi, developer cảm thấy họ đã sai và muốn xóa đi làm lại từ đầu, việc revert là hành động để khôi phục trạng thái của 1 hay nhiều document về 1 revision nào đó, thường thì sẽ revert về revision hiện tại mà user đang làm việc
  • merge: việc gộp code từ nhiều branch khác lại làm một được gọi là Merge, branch thứ hai sẽ chuyển hướng về branch đầu tiên
  • update: việc update working copy sẽ chuyển working copy sang revision mà user lựa chọn

Dĩ nhiên, còn nhiều nữa nhưng những cái quan trọng thì chỉ thế thôi.

Tool

Rất nhiều developer hiện tại thích dùng CLI để giao tiếp với SVN vì tính đơn giản của nó. Nhưng cũng có người này người kia, một số khác thích dùng GUI cho nó đỡ đau đầu. Khi xài GUI, tool là thứ cần thiết. Với Mac, Cornerstone và Versions là 2 client SVN tốt nhất, còn Windows dĩ nhiên là TortoiseSVN, free và open source. Ngoài ra còn rất nhiều các SVN client tốt khác, nhưng mình thì không quan tâm lắm.

Okay, phần 1 đến đây là hết, phần sau mình sẽ đi sâu vào 1 số lệnh và kiến trúc phía server-side của SVN, cũng như nói qua về một hệ thống cũ hơn là CVS – Concurrent Versioning System.

Chúc mọi người một buổi chiều làm việc vui vẻ!