-
Dựa trên lý thuyết patch nhưng vẫn nhanh và có khả năng mở rộng
-
Commutation
→ Mỗi thay đổi có thể được áp dụng theo bất kỳ thứ tự nào mà không làm thay đổi version id
→ Quy trình làm việc đơn giản hơn nhiều so với git rebase hoặc hg transplant
→ Có tính năng channels tương tự branch nhưng không quá quan trọng như trong các hệ thống khác. Ví dụ, một feature branch trong Pijul chỉ đơn giản là một thay đổi
→ Việc giữ lịch sử gọn gàng là thiết lập mặc định
- Merge correctness
→ Pijul đảm bảo một số điều khi thực hiện merge
→ Điều quan trọng nhất là thứ tự các dòng luôn được giữ nguyên. Khác với merge 3 chiều đôi khi làm các dòng bị xáo trộn
→ Khi không thể xác định thứ tự (chẳng hạn như khi chỉnh sửa đồng thời), nó sẽ trở thành conflict, đây là điểm khác biệt với các hệ thống coi đó là "Automatic" hoặc "No Conflict"
- First-class conflicts
→ Trong Pijul, conflict không phải là "merge thất bại" mà được mô hình hóa như một trường hợp tiêu chuẩn
→ Đặc biệt, conflict phát sinh giữa hai thay đổi sẽ được giải quyết bằng một thay đổi duy nhất
- Partial Clones
→ Với Commutation, có thể chỉ clone một tập con nhỏ của kho lưu trữ. Trên thực tế, cũng có thể chỉ áp dụng các thay đổi cho chính tập con đó
→ Công việc liên quan đến Partial Clone tạo ra các Changes có thể dễ dàng gửi tới các kho lưu trữ quy mô lớn
3 bình luận
Thú thật là Git đúng là tiêu chuẩn trong công việc thực tế nên vẫn phải dùng, nhưng nó cực kỳ bất tiện -- Đến lúc nên dần dần chuyển sang Pijul nền tảng Rust rồi
Điểm khác biệt lớn nhất giữa svn và git (ngoài việc là kho lưu trữ phân tán) là svn quản lý diff, trong khi git quản lý snapshot; nghe nói đây là lý thuyết patch nên tôi có cảm giác nó có lẽ thuộc phía quản lý diff.
Lý thuyết bản vá (Theory of Patches) có thể xem trong Darcs, một hệ thống quản lý phiên bản phân tán.
Khi so sánh Darcs và Git, người ta giải thích như sau.
Một tập hợp các thay đổi mà bạn ghi lại trong Git được gọi là một “commit”, còn trong Darcs thì được gọi là một “patch”.