Subversion: Có thể thực hiện nhiều thao tác sao chép trong một bản sửa đổi duy nhất không?

Question

Từ những gì tôi hiểu về các giao dịch trong Subversion, điều này có thể về nguyên tắc, nhưng tôi không biết bất kỳ công cụ nào hỗ trợ nó.

Nền tảng là chúng tôi đang thảo luận về việc di chuyển từ PVCS Kích thước thành Subversion và tính năng chính được trích dẫn là bị thiếu trong Subversion là "Design Parts". Phần thiết kế là một tập hợp tùy ý các tệp có thể được xử lý cùng nhau, ví dụ: tất cả các tệp nguồn cần thiết cho một tiểu dự án.

Một ý tưởng để thay thế điều này là bằng thao tác sao chép trong tệp Makefile, sao chép các tệp có liên quan vào nhánh. Nhưng nếu tất cả các tệp được sao chép riêng biệt, điều này có thể dẫn đến nhiều bản sửa đổi, điều này có thể làm lộn xộn lịch sử, vì vậy sẽ rất tuyệt nếu bạn tránh điều đó.

EDIT: Một số thông tin cơ bản:

Dự án bao gồm một số (5-10) tiểu dự án được phát hành riêng lẻ, nhưng mà chia sẻ một số file nguồn chung và thư viện bên ngoài được nhập khẩu từ các dự án khác.

Một lý do được trích dẫn cho các phần thiết kế là hạn chế phụ thuộc vào tệp nguồn, cách khác là quản lý sản phẩm của tiểu dự án, để tất cả chúng có thể được cập nhật trong điều khiển phiên bản trong một thao tác. Cả hai loại tệp đều được rải rác trên các thư mục.

Chúng tôi có khoảng 5 nhà phát triển trong dự án.

Answer 1

Bạn có thể sao chép bản sao làm việc và cam kết tất cả cùng một lúc sau đó. Điều đó chỉ tạo ra một bản sửa đổi.

Với dòng lệnh-client nó có thể trông như thế:

svn copy file1 directory 
svn copy file2 directory 
svn copy file3 directory 
svn commit 

Nhược điểm chính là bạn cần một lao động sao chép và điều này làm việc sao y bản chính phải bao gồm source và mục tiêu-thư mục.

Answer 2

Tại sao bạn không đặt tiểu dự án của mình vào một thư mục con riêng.

Project 
    | 
    ---> Subproject 1 
    ---> Subproject 2 
    Files from project. 

Bằng cách này, bạn luôn có thể hoạt động trên một tiểu dự án hoàn chỉnh.

Ở đây chúng ta có:

Project 
    | 
    ---> common Files 
    ---> Subprojects... 

Answer 3

Nếu tất cả các dự án đang trong kho riêng của họ, svn externals có thể làm các trick

Answer 4

Có một svnmucc công cụ mà thực hiện chính xác này, mà không đòi hỏi một bản sao làm việc:

http://subversion.tigris.org/tools_contrib.html#svnmucc_c

Answer 5

này khá thú vị, tôi vừa mới một cách nhanh chóng đọc trên các bộ phận thiết kế, từ những gì tôi có thể thu thập, bởi phân chia các tệp một cách hiệu quả thành cấu trúc tùy ý, bạn sẽ hướng đến một thế giới đau đớn khi bạn bắt đầu hợp nhất mọi thứ trở lại vị trí ban đầu của chúng (và việc hợp nhất có thể sẽ không được thực hiện trong một cam kết duy nhất trên tất cả các tập tin).

Nhưng tôi nghĩ rằng bạn có thể làm một điều tương tự để thiết kế bộ phận trong lật đổ với một chút tinh chỉnh:

Thứ nhất, một phần thiết kế có thể được mô phỏng sử dụng externals (1.6 cho phép externals để trỏ đến file cũng như các thư mục). Để làm điều này, bạn có thể thiết lập hệ thống cấp bậc dự án của bạn như thế này:

/project1 
/trunk 
    /doc 
    /design1 
    /release2 
    /src 
    /subproject1 
    /subproject2 
/tags 
/branches 
/parts 
    /part1 
    /part2 
    /part3 

Mỗi thư mục phần sẽ chỉ chứa một "svn: externals" tài sản đó mang lại trong các tập tin thích hợp cho điều đó phần vào phân kho thích hợp, như:

svn:externals 

../../trunk/src/subproject1  src/subproject1 
../../trunk/doc/release2   doc/release2 

sau đó bạn kiểm tra các bộ phận, chứ không phải là thân cây, và bạn nhận được một bản sao làm việc mà chỉ chứa các tập tin mà bạn muốn trong cấu trúc mà phần định nghĩa, và khi bạn cam kết, bạn đang đi thẳng vào thân cây - không cần hợp nhất ở đây.

Bạn cũng có thể căn bản các bộ phận của mình bằng cách đầu tiên phân nhánh toàn bộ thân cây (giá rẻ và nhanh), sau đó thay đổi phần bên ngoài để trỏ đến nhánh thay vì thân chính. Điều này không làm tăng kích thước của kho lưu trữ, và bản sao làm việc của bạn giữ chính xác cấu trúc tương tự, bạn chỉ tìm nguồn cung ứng tất cả các tập tin của bạn từ chi nhánh chứ không phải là thân cây. Bất kỳ bản cập nhật nào cho phần đó cũng đi ngược lại nhánh - việc hợp nhất các thay đổi của phần này chỉ là một hợp nhất tái tích hợp chuẩn của nhánh trở lại vào thân cây, đó là thực hành chuẩn svn.

Quản lý định nghĩa các bộ phận trở nên thú vị hơn, vì trong sơ đồ trên, mỗi phần được xác định theo cách thủ công và chúng không phân cấp. Bạn sẽ cần một số dạng script (có lẽ makefile) mà biết phân cấp các phần và được đặt tên một phần, có thể xây dựng các định nghĩa bên ngoài thích hợp mà sau đó có thể được áp dụng cho một thư mục phần. Vì vậy, trong khi subversion không cung cấp một cách rõ ràng lớp trừu tượng của các bộ phận, nó có thể được mô hình thủ công khá chính xác - bạn chỉ bị giới hạn bởi khả năng của svn: externals và các script mà bạn sử dụng để quản lý chúng.

Answer 6

Bạn có thể sử dụng: svn copy FROM_URL1 FROM_URL2 URL_TO

Ví dụ:

svn copy svn://192.168.1.50/trunk/folder1 svn://192.168.1.50/trunk/folder2 svn://192.168.1.50/tags/MY_TAG 

Answer 7

tôi đã phải đối mặt với vấn đề tương tự: làm thế nào để sao chép một số tập tin, rải rác trong kho lưu trữ vào thẻ và làm cho nó nhanh chóng trong một giao dịch như vậy, một bản sửa đổi. đơn giản nhất Cách thứ nhất là để tạo ra tạm thời thư mục Làm việc Copy, sao chép tất cả các file cần thiết ở đó và sau đó sao chép Sao chép công tác địa phương để kho từ xa và gỡ bỏ thư mục tạm thời:

svn mkdir TMP_DIR 
svn mkdir TMP_DIR\MY_TAG 
svn cp --parents src\test\File.txt TMP_DIR\MY_TAG\src\test\File.txt 
svn cp --parents src\test2\File2.txt TMP_DIR\MY_TAG\src\test2\File2.txt 
svn cp -m "comment" TMP_DIR\MY_TAG "http://myrepohost/myrepo/tags/" 
svn rm --force TMP_DIR 

hy vọng rằng sẽ giúp.

Answer 8

tổ chức công việc/code của bạn là sai:

nếu bạn đã bị chia sẻ mã giữa gói riêng biệt, điều này thuộc rõ ràng vào một riêng biệt. một cây cho mỗi gói.

đặt một số gói (các phiên bản cụ thể) lại với nhau thành một số môi trường thuộc vào một lớp riêng biệt ở trên (ví dụ như một sản phẩm phần mềm lớn hơn bao gồm một số, có thể tùy chọn, thành phần.): Các distro, và được xử lý bởi cơ sở hạ tầng quản lý gói của distro.