Nếu bạn là người sử dụng hoặc quản trị hệ thống mà đang cân nhắc sử dụng Subversion, câu hỏi đầu tiên mà bạn nên tự hỏi mình là: "Đây có phải là công cụ phù hợp cho công việc hay không?" Subversion là một cái búa tuyệt vời, nhưng hãy cẩn thận đừng xem tất cả các vấn đề như một móng tay.

Như bước khởi đầu, bạn cần quyết định nếu kiểm soát phiên bản nói chung là cần thiết cho các mục đích của bạn. Nếu bạn cần lưu trữ những phiên bản cũ của tập tin và thư mục, có nhu cầu phục hồi chúng, và kiểm tra các bản ghi nhật ký để xem chúng được thay đổi như thế nào xuyên suốt thời gian thì kiểm soát phiên bản có thể làm được. Nếu bạn cần hợp tác với nhiều người trên những tài liệu (thông thường là trên hệ thống mạng) và theo dõi việc ai thay đổi những gì, kiểm soát phiên bản cũng có thể làm được. Trên thực tế, đó là lý do vì sao những công cụ kiểm soát phiên bản như là Subversion thường được sử dụng trong môi trường phát triển phần mềm—làm việc trong một nhóm phát triển vốn là một hoạt động xã hội nơi mà việc thay đổi trên tập tin mã nguồn liên tục được thảo luận, thực hiện, đánh giá, và kể cả đôi khi phá bỏ. Những công cụ kiểm soát phiên bản tạo điều kiện cho loại hợp tác này.

Việc sử dụng kiểm soát phiên bản tất nhiên cũng có một số hạn chế. Trừ khi bạn có thể thuê ngoài việc quản trị hệ thống kiểm soát phiên bản của bạn cho bên-thứ-ba, việc tự bạn quản lý hệ thống vẫn có một số mặt hạn chế. Khi làm việc với dữ liệu trên cơ sở hàng ngày, bạn không thể sao chép, di chuyển, đổi tên hoặc xoá tập tin theo cách mà bạn thường làm. Thay vào đó, bạn sẽ phải thực hiện tất cả những việc đó thông qua hệ thống kiểm soát phiên bản.

Ngay cả giả sử rằng bạn hài lòng với sự cân bằng về mặt hạn-chế/lợi-ích mà hệ thống kiểm soát phiên bản mang lại, bạn cũng không nên chọn sử dụng chỉ đơn thuần bởi vì nó có thể làm được những gì bạn muốn. Nên cân nhắc nhu cầu của bạn có thể được giải quyết bằng các công cụ khác. Ví dụ, bởi vì Subversion sao chép dữ liệu đến tất cả các cộng tác viên liên quan, một sự lạm dụng phổ biến đó là xem nó như một hệ thống phân phối. Đôi khi người ta sử dụng Subversion để phân phối những bộ sưu tập lớn hình ảnh, âm nhạc kỹ thuật số, hoặc những gói phần mềm. Vấn đề là tất cả những loại dữ liệu này thường không thay đổi. Bản thân bộ sưu phồng lên theo thời gian, nhưng những tập tin riêng lẽ trong bộ sưu tập thì không thay đổi. Trong trường hợp này, việc sử dụng Subversion là “quá mức cần thiết”.^[2] Có nhiều công cụ đơn giản hơn để sao chép dữ liệu một cách hiệu quả mà không tốn thêm chi phí với phần theo dõi những thay đổi, ví dụ như rsync hoặc unison.

Một khi bạn đã quyết định rằng bạn cần một giải pháp kiểm soát phiên bản, bạn sẽ tìm thấy không thiếu những lựa chọn có sẵn. Ở thời điểm khi Subversion lần đầu được thiết kế và phân phối, phương pháp thống trị của kiểm soát phiên bản là kiểm soát phiên bản tập trung hoá—một tổng kho đơn từ xa chứa dữ liệu phiên bản với người dùng cá nhân làm việc cục bộ trên bản sao cạn (shallow copy) lịch sử phiên bản của dữ liệu. Subversion nhanh chóng nổi lên sau lần giới thiệu ban đầu như là một tiên phong trong lĩnh vực kiểm soát phiên bản, được tiếp nhận một cách rộng rãi và là giải pháp thay thế cho nhiều hệ thống kiểm soát phiên bản cũ hơn. Ngày nay nó tiếp tục nắm giữ vị trí nổi bật.

Tuy nhiên, đã có nhiều thay đổi kể từ đó. Trong những năm kể từ thời điểm dự án Subversion bắt đầu vòng đời của nó, một phương pháp kiểm soát phiên bản mới được gọi là kiểm soát phiên bản phân tán đã tương tự như vậy thu hút được sự chú ý và chấp nhận rộng rãi. Những công cụ như là Git (http://git-scm.com/) và Mercurial (http://mercurial.selenic.com/) đã nổi lên trên đỉnh xếp hạng của hệ thống kiểm soát phiên bản phân tán (DVCS). Hệ thống kiểm soát phiên bản phân tán khai thác sự phát triển phổ biến của kết nối mạng tốc độ cao và chi phí lưu trữ thấp để cung cấp một cách tiếp cận khác với mô hình tập trung ở những điểm chính. Trước tiên và rõ ràng nhất đó là thực tế không có tổng kho trung tâm của dữ liệu được đánh dấu phiên bản. Thay vào đó, mỗi người dùng lưu giữ và vận hành một phiên bản cục bộ đầy đủ—đầy đủ, theo một nghĩa nào đó—về lịch sử lưu trữ dữ liệu. Việc hợp tác vẫn xảy ra, nhưng được thực hiện thông qua việc trao đổi tập của những thay đổi được tạo trực tiếp giữa những bản dữ liệu lưu trữ cục bộ của người dùng, không phải thông qua lưu trữ dữ liệu tổng thể tập trung. Trên thực tế, bất kỳ hình thái nào của dữ liệu phiên bản của bộ dữ liệu của dự án chỉ là theo quy ước, một trạng thái được quy gán bởi các cộng tác viên khác nhau trong dự án đó.

Với mỗi hướng tiếp cập của kiểm soát phiên bản tồn tại những ưu và khuyết điểm. Có lẽ hai lợi ích lớn nhất được cung cấp bởi các công cụ DVCS là hiệu suất đáng kinh ngạc cho hoạt động hàng ngày (bởi vì dữ liệu chính được lưu trữ cục bộ) và hỗ trợ tốt hơn một cách rộng rãi cho việc hợp nhất giữa các nhánh (vì thuật toán hợp nhất đóng vai trò cốt lõi trong cách DVCS làm việc). Nhược điểm là kiểm soát phiên bản phân tán vốn là một mô hình phức tạp hơn, mà có thể hiện hữu một thách thức đáng kể ảnh hưởng tới tính tiện lợi của việc cộng tác. Ngoài ra, công cụ DVCS làm rất tốt cũng một phần vì một mức độ nhất định của kiểm soát nằm ở phía người dùng mà về cơ bản hệ thống tập trung cung cấp—khả năng thực hiện việc kiểm soát truy cập dựa trên đường dẫn, tính linh hoạt để có thể cập nhật hoặc huỷ cập nhật những mục dữ liệu phiên bản riêng lẻ, vv. May mắn thay, nhiều tổ chức sáng suốt đã phát hiện ra rằng điều này không cần phải là một cuộc tranh luận tôn giáo, công cụ Subversion và DVCS như là Git có thể sử dụng chung với nhau một cách hài hoà trong tổ chức, mỗi công cụ phục vụ cho một mục đích riêng phù hợp với nó.

Cuốn sách này là về Subversion, vì vậy chúng tôi sẽ không cố gắng làm một so sánh đầy đủ của Subversion và các công cụ khác. Độc giả được trao quyền để lựa chọn hệ thống kiểm soát phiên bản của họ và được khuyến khích nghiên cứu các tùy chọn có sẵn để có lựa chọn phù hợp nhất cho bản thân và cộng tác viên của họ. Và nếu sau khi ra quyết định, Subversion được chọn, có nhiều thông tin chi tiết về cách làm thế nào để sử dụng nó một cách thành công trong các chương tiếp theo!

Trong những năm đầu 2000, CollabNet, Inc. (http://www.collab.net) bắt đầu chiêu mộ nhiều lập trình viên để xây dựng một bản thay thế cho CVS. CollabNet cung cấp^[3] một bộ phần mềm cộng tác gọi là CollabNet Enterprise Edition (CEE), trong đó có một thành phần là kiểm soát phiên bản. Mặc dù ban đầu CEE dùng CVS làm hệ thống kiểm soát văn bản, những giới hạn của CVS là rõ ràng ngay từ ban đầu, và CollabNet biết là họ cuối cùng cần phải tìm một cái gì đó tốt hơn. Không may là CVS trên thực tế đã trở thành tiêu chuẩn trong phần lớn thế giới mã nguồn mở bởi vì không có cái nào tốt hơn, ít nhất là theo một giấy phép miễn phí. Vì vậy CollabNet đã quyết định xây dựng một hệ thống kiểm soát phiên bản mới hoàn toàn, giữ lại những ý tưởng cơ bản của CVS nhưng không có lỗi và bổ sung những tính năng còn thiếu.

Vào tháng 2 năm 2000, họ liên lạc với Karl Fogel là tác giả của Phát Triển Mã Nguồn Mở với CVS (Coriolis, 1999) và đề nghị ông tham gia vào dự án. Thật trùng hợp, lúc đó Karl đang thảo luận với bạn của mình Jim Blandy về việc thiết kế một hệ thống kiểm soát phiên bản mới. Trong năm 1995, cả hai đã mở công ty Cyclic Software là công ty chuyên cung cấp hợp đồng hỗ trợ CVS, và mặc dù sau đó đã bán công ty nhưng họ vẫn sử dụng CVS để làm việc hàng ngày. Sự thất vọng của họ với CVS đã khiến Jim phải suy nghĩ cẩn thận về những cách tốt hơn để kiểm soát dữ liệu phiên bản và ông đã không chỉ nghĩ ra cái tên Subversion mà còn xây dựng được những thiết kế cơ bản của dữ liệu lưu trữ Subversion. Khi CollabNet liên hệ, Karl ngay lập tức đồng ý tham gia vào dự án, và Jim có được chủ nhân của mình, Công ty Phần mềm Red Hat, để về cơ bản cống hiến cho dự án vô thời hạn. CollabNet thuê Karl và Ben Collins-Susman và việc thiết kế chi tiết đã bắt đầu vào tháng Ba năm 2000. Với sự giúp đỡ từ Brian Behlendorf và Jason Robbins của CollabNet, và từ Greg Stein (lúc đó là một nhà phát triển tự do chuyên về quy trình đặc điểm kỹ thuật WebDAV/DeltaV), Subversion nhanh chóng thu hút được một cộng đồng những nhà phát triển tích cực. Hoá ra có rất nhiều người có trải nghiệm thất vọng với CVS và họ hoan nghênh cơ hội để cuối cùng làm gì đó để giải quyết việc này.

Nhóm thiết kế ban đầu thiết lập một số mục tiêu. Họ không muốn thiết lập một tiêu chuẩn mới trong phương pháp kiểm soát phiên bản, họ chỉ muốn sửa CVS. Họ quyết định rằng Subversion sẽ đồng nhất với CVS về mặt tính năng và bảo tồn y nguyên mô hình phát triển, nhưng không lặp lại những lỗi quá rõ ràng của CVS. Và mặc dù nó không cần phải là một sự thay thế cho CVS, nó nên giống vừa đủ để bất kỳ người dùng nào cũng có thể thực hiện chuyển đổi với rất ít nỗ lực.

Sau 14 tháng lập trình, Subversion bắt đầu “tự-lưu-trữ” vào ngày 31 tháng 8 năm 2001. Đó là, các nhà phát triển Subversion ngừng sử dụng CVS để quản lý mã nguồn riêng của Subversion và bắt đầu sử dụng Subversion để thay thế.

Trong lúc CollabNet bắt đầu dự án và vẫn đang đóng góp một phần lớn công việc (trả lương cho một số lập trình viên Subversion làm việc toàn thời gian), Subversion được duy trì như đa số những dự án mã nguồn mở khác, quản lý bởi một tập hợp lỏng lẻo, các quy tắc minh bạch nhằm khuyến khích nhân tài. Trong năm 2009, CollabNet đã làm việc với những nhà phát triển Subversion hướng tới mục tiêu tích hợp dự án Subversion vào Quỹ Phần mềm Apache (ASF - Apache Software Foundation), một trong những tập thể nổi tiếng nhất trên thế giới của dự án mã nguồn mở. Kỹ thuật gốc của Subversion, hướng đến cộng đồng và thực tiễn phát triển là phù hợp hoàn hảo với ASF, nhiều người trong số các thành viên đã là những người đóng góp tích cực vào Subversion. Vào đầu năm 2010, Subversion được tiếp nhận hoàn toàn vào danh sách những dự án quan trọng của ASF, chuyển địa chỉ website của dự án tới http://subversion.apache.org và được đặt lại tên là “Apache Subversion”.

Figure 1, “Kiến trúc Subversion” minh hoạ “mile-high” thiết kế của Subversion.

Figure 1. Kiến trúc Subversion

Ở một phía là kho lưu trữ Subversion lưu giữ toàn bộ dữ liệu phiên bản của bạn. Ở phía còn lại là ứng dụng khách quản lý cục bộ phần phản xạ của những phần dữ liệu phiên bản. Giữa hai cực đó là rất nhiều tuyến đường xuyên qua một lớp Quyền Truy Cập Kho Lưu Trữ (RA - Repository Access), một số trong đó thông qua mạng máy tính kết nối vào các máy chủ mạng mà sau đó truy cập vào kho lưu trữ, số khác bỏ qua mạng hoàn toàn và truy cập trực tiếp vào kho lưu trữ.

Subversion, sau khi cài đặt, có một số phần khác nhau. Sau đây là tổng quan của những gì bạn nhận được. Đừng lo lắng nếu phần mô tả làm cho bạn phải gãi đầu—rất nhiều trang trong cuốn sách này được dành để làm giảm bớt sự rối rắm này.

Ấn bản đầu tiên của cuốn sách này được phát hành bởi O'Reilly Media vào năm 2004, ngay sau khi Subversion hoàn thành phiên bản 1.0. Kể từ đó, dự án Subversion tiếp tục phát hành phiên bản chính mới của phần mềm. Đây là bản tóm tắt của những thay đổi chính kể từ Subversion 1.0. Lưu ý rằng đây không phải là một danh sách hoàn chỉnh; để có đầy đủ thông tin chi tiết, vui lòng truy cập website của Subversion tại địa chỉ http://subversion.apache.org.