SVN: Cách tốt nhất để chia sẻ mã phổ biến trên các dự án

Question

Tôi có nhiều dự án trang web trong một kho lưu trữ duy nhất mà mỗi bản có một bản sao của WordPress. Cập nhật WordPress có nghĩa là cập nhật tất cả các thư mục dự án và giữ các bản sao dự phòng. Điều này rất hữu ích cho các kịch bản rsync của tôi mà đồng bộ hóa toàn bộ thư mục. Nó cũng cung cấp cho tôi bản sao cục bộ làm việc đầy đủ của trang web.

Có một số cách tôi có thể thấy để cải thiện điều này và muốn một số phản hồi. Tôi đang trên Windows và gần đây đã di chuyển sang Subversion.

1. Tạo liên kết tượng trưng cho các bit WordPress trong mỗi thư mục trang web. Điều này sẽ giữ trong Subversion và Apache. Có bất kỳ hạn chế nào không?
2. Có một thư mục WordPress duy nhất và phân nhánh nó vào các thân trang web khác. Tôi đọc rằng các chi nhánh có giá rẻ và một bản duy nhất được duy trì nhưng tôi không chắc chắn nếu phân nhánh nên được thực hiện trên thân cây. Cá nhân tôi nghĩ đây là cách tiếp cận tốt nhất. Có lý do gì để tránh điều này không?
3. Cuối cùng, tôi có thể giữ cấu trúc hiện tại và sử dụng tập lệnh để tạo bản sao trên tất cả các thư mục trang web.

Cách tiếp cận tốt nhất và có giải pháp thay thế nào không?

Answer 1

Một tùy chọn sẽ là tách các bit WordPress ra thành một kho lưu trữ riêng biệt (vì nó không thực sự là một phần của dự án của bạn, nó chỉ là thứ bạn sử dụng để xây dựng chúng), và sau đó sử dụng svn: externals để tìm nạp dự án của bạn ở đúng vị trí.

Externals Definitions in the SVN book

Answer 2

Bạn có thể thêm một trỏ svn:external nét đến WordPress repository hoặc làm của riêng riêng biệt "tùy chỉnh WordPress Repository" của bạn với các plugins và tùy chỉnh mà bạn sử dụng.

Answer 3

Có lẽ tôi chỉ sử dụng Subversion một cách sai lầm, nhưng cấu trúc thư mục của chúng tôi trông giống như sau

Trunk - Core - Tin nhắn - Super mạnh mẽ ứng dụng # 1 - Super mạnh mẽ ứng dụng # 2 - Ứng dụng siêu mạnh # 3

Vì vậy, tất cả các ứng dụng của chúng tôi đều có chung các thành phần Cốt lõi và Nhắn tin. Nhược điểm duy nhất cho điều này là khi mọi người chi nhánh, họ nhận được tất cả các ứng dụng, nhưng đó là nhiều hơn một khó chịu hơn bất cứ điều gì.

Answer 4

Điều này thường xảy ra khi tôi sử dụng lại cùng một thư viện lớp cho các dự án khác nhau và trong trường hợp của tôi, tôi muốn có một bản sao riêng biệt cho từng dự án. Lý do duy nhất là tôi không muốn phá vỡ các dự án mà tôi đã không làm việc trong một thời gian trong trường hợp một trong các thư viện đã lỗi thời nó. Tuy nhiên, nếu mỗi dự án là một phần của một loại dự án chính bạn liên tục làm việc trên nó thì khác.

Answer 5

Cách tốt hơn để làm điều này là kéo wordpress ra thành một nhánh riêng biệt của kho lưu trữ của bạn. Sau đó, giới thiệu một tệp cấu hình cho từng trang web lưu trữ đường dẫn đến Wordpress. Bạn có thể nối thêm vị trí này vào đường dẫn php của bạn. Dưới đây là một sơ đồ:

này có một vài ưu điểm:

• Bạn có thể thử nghiệm với một số phiên bản của Wordpress cùng một lúc, để làm thử nghiệm và những gì-không.Bạn có thể chia sẻ chúng giữa tất cả các trang web
• Bạn sẽ không phải lo lắng về việc wordpress đang kiểm tra ở đâu. Bao gồm một thư viện trong một dự án thường lộn xộn, nhưng loại thiết lập này giúp việc đặt mọi thứ ở một số vị trí phổ biến trở nên dễ dàng hơn.
• Bạn không phải duy trì nhiều phiên bản của thư viện, việc cập nhật dễ dàng hơn nhiều.

Answer 6

Theo truyền thống, mọi thứ nên được phân tách trên SVN. Có vẻ như bạn đang sử dụng SVN như một phương tiện để lấy mã từ các khu vực khác nhau và ghép chúng lại với nhau.

Vì vậy, bạn đang sử dụng SVN làm công cụ xây dựng. Nó tốt hơn để:

• giữ các plugins của bạn tách
• không lưu trữ tự wordpress trong SVN, trừ khi bạn sử dụng một chi nhánh nhà cung cấp
• khi bạn cần phải lấy một ứng dụng cụ thể với các thành phần cụ thể, làm việc với một build-script.

Answer 7

Nếu bạn đã lưu trữ tất cả các trang web cùng nhau trong một kho lưu trữ, svn: externals có thể được sử dụng để kéo các phần khác nhau của cùng một kho lưu trữ theo nhiều cách khác nhau.

Ví dụ: với một kho lưu trữ như

 
repo/site1 
repo/site2 
repo/commonPieces 

Bạn có thể giới thiệu một "svn: externals" tài sản trên site1 và dirs site2 nói rằng "commonPieces url-to-repo/commonPieces".

Bạn sẽ muốn tránh mọi vòng lặp đệ quy ở đây rõ ràng. Nhưng điều này có lợi thế là mọi thứ trong cùng một kho lưu trữ và có thể chia sẻ lịch sử - bạn có thể kéo những thứ đang trở nên phổ biến hơn từ site1 hoặc site2 thành commonPieces sử dụng "svn copy".

Hãy so sánh giải pháp hiện tại của chúng tôi, nơi tôi đang làm việc - di cư thứ từ kho dự án riêng của chúng tôi vào một đơn cũng-riêng "coreLibraries" kho mất lịch sử phát triển. Vì chúng ta thường phát triển tính năng cho một dự án và sau đó quyết định tái sử dụng chúng, sự mất mát này của lịch sử xảy ra rất nhiều ...

---

Edit: nó có giá trị ghi nhớ rằng trong khi "svn update" trên site1 sẽ tự động cập nhật commonPieces với thuộc tính "svn: externals" tại chỗ, "cam kết svn" trên site1 sẽ không hiển thị những thứ đã thay đổi trong site1/commonPieces. Bạn sẽ phải thực hiện hai cam kết riêng biệt, một từ site1 và một từ site1/commonPieces.

Answer 8

Cách tiếp cận tốt nhất và có giải pháp thay thế nào không?

Không đi tắt chủ đề, nhưng tôi đề nghị bạn tham gia một cái nhìn nghiêm khắc git. Chúng tôi làm điều này loại ngày điều này qua ngày khác với các môđun con, và nó là một làn gió.

FYI - di cư từ SVN khoảng 2 năm trước do các loại vấn đề này.