Kiểm soát phiên bản để cộng tác (với khác biệt cấp độ từ)?


20

Hầu hết các bài báo hiện được viết một cách hợp tác và các cộng tác viên thường được đặt ở những nơi khác nhau. Tôi đã luôn sử dụng các hệ thống kiểm soát phiên bản cho các tài liệu và mã của mình và cũng thấy việc kiểm soát phiên bản rất quan trọng đối với các dự án phần mềm hợp tác, nhưng có vẻ như nhiều nhà nghiên cứu về lý thuyết tránh sử dụng để viết các bài báo chung. Để thuyết phục các cộng tác viên của tôi rằng kiểm soát phiên bản (kiểm soát sửa đổi) là một ý tưởng tốt để làm việc cùng nhau, dường như có một số điều kiện tiên quyết. Không thể buộc tất cả mọi người phải lo lắng về một bộ quy ước cụ thể cho ngắt dòng và đoạn văn, hoặc để tránh chuyển đổi tab / không gian.

Có ai đó cung cấp lưu trữ miễn phí các kho tài liệu chia sẻ nhỏ, với kiểm soát phiên bản thân thiện với tài liệu văn bản có thể xử lý các khác biệt ở cấp độ từ ( không dựa trên dòng) không?

Nếu không, thì tôi sẽ hoan nghênh các đề xuất khác dựa trên kinh nghiệm (vui lòng tránh đầu cơ, làm ơn).

Tôi đã nghĩ đến Git, Subversion, Mercurial, darcs hoặc Bazaar, được thiết lập để xử lý các khác biệt về cấp độ từ với wdiff, cùng với một cách đơn giản để thiết lập quyền truy cập được bảo mật bởi các khóa công khai (ví dụ qua ssh). Tuy nhiên, không có nhà cung cấp kiểm soát phiên bản nào mà tôi nhìn vào dường như cung cấp bất cứ thứ gì như thế này. Đối với sự hợp tác khoa học, các tính năng "doanh nghiệp" được nhấn mạnh bởi nhiều công ty này không quan trọng lắm (rất nhiều chi nhánh, tích hợp với trac, kiểm toán của bên thứ ba, nhóm dự án phân cấp). Nhưng khác biệt cấp độ từ có vẻ quan trọng nhưng không được hỗ trợ. Theo kinh nghiệm của tôi, với các khác biệt ở cấp độ dòng cho các tệp văn bản, mọi người phải tránh việc định dạng lại các đoạn văn và trình chỉnh sửa thay đổi các tab thành khoảng trắng hoặc ngược lại gây ra sự cố; dường như cũng có nhiều xung đột chỉnh sửa giả.

Xem câu hỏi liên quan tại MO về các công cụ để cộng tác và các câu hỏi liên quan tại TeX.SE, về kiểm soát phiên bản cho các tài liệu LaTeXcác gói LaTeX để kiểm soát phiên bản . Xem thêm Biểu đồ đánh giá so sánh máy chủ SVN để biết danh sách lớn các nhà cung cấp dịch vụ lưu trữ, chỉ với một trong các hệ thống kiểm soát phiên bản chính.


Chỉnh sửa: Câu trả lời Jukka Suomela của cho câu hỏi TeX.SE " diff LaTeX-aware và hợp nhất các công cụ tốt nhất cho lật đổ " dường như là gợi ý tốt nhất cho đến nay, bao gồm làm thế nào để giải thích các vùng đồng bằng về mặt kĩ từ. Hơn nữa, Jukka đã giải thích sự khác biệt giữa các phiên bản kế tiếp ở cuối kho lưu trữ tách biệt với sự khác biệt ở cấp độ người dùng được sử dụng để phát hiện xung đột và hợp nhất các thay đổi. Câu trả lời của Jukka tại TeX.SE loại trừ rõ ràng việc chỉnh sửa và hợp nhất đồng thời, thay vào đó dựa vào mã thông báo chỉnh sửa nguyên tử truyền thống để tránh xung đột chỉnh sửa. Làm rõ (và sửa đổi) câu hỏi ban đầu của tôi, có cách nào để đảm bảo rằng các xung đột chỉnh sửa có thể được giải quyết trên cơ sở khác biệt từ, thay vì trên cơ sở khác biệt về dòng không? Nói cách khác, có thểwdiffhoặc các công cụ tương tự được tích hợp vào phần phát hiện xung đột của các công cụ kiểm soát phiên bản, tương tự như cách có thể bỏ qua sự khác biệt và khác biệt cuối dòng trong khoảng trắng?


3
Tôi không hiểu câu hỏi. Ví dụ, trong SVN, các khác biệt được hiển thị cho người dùng được tạo bởi ứng dụng khách và nó phụ thuộc vào ứng dụng khách SVN của bạn (và cấu hình của nó) cho dù bạn có tìm khác biệt dựa trên từ hoặc khác biệt dựa trên dòng. Công ty lưu trữ kho SVN của bạn hoàn toàn không ảnh hưởng đến điều này.
Jukka Suomela

2
@suresh Nếu bạn đang chỉnh sửa (bằng văn bản) tài liệu văn bản, thường sẽ rất khó khăn khi phải quét toàn bộ một dòng trong một khác biệt để thấy rằng ai đó đã thay đổi một dấu phẩy. Hành vi đúng thường là hiển thị đơn vị thay đổi tối thiểu. Hoặc, xem xét hành vi nếu ai đó không sử dụng ngắt dòng. Sau đó, thay đổi một từ duy nhất sẽ khiến toàn bộ đoạn hiển thị trong diff để bạn tìm thấy sự thay đổi nhỏ.
Đánh dấu Reitblatt

2
Tôi không sử dụng ngắt dòng cứng để bọc dòng. Trong mã nguồn latex của tôi, một dòng văn bản vật lý thường là một đoạn văn bản đầy đủ. Trình chỉnh sửa có thể bọc từ để hiển thị, tùy thuộc vào chiều rộng cửa sổ hiện tại. Nó đơn giản hóa mọi thứ rất nhiều; không bao giờ cần phải lo lắng về những điều như tôi nên viết lại một đoạn văn hay đồng ý về độ rộng dòng "đúng" với các đồng tác giả của bạn. Tuy nhiên, bạn sẽ cần một công cụ tìm mức độ từ để xem các thay đổi nhanh chóng.
Jukka Suomela

2
@Andras Quan điểm của tôi là hệ thống VC chỉ cần có khả năng tái cấu trúc hai bản sửa đổi ở phía máy khách, và không ngạc nhiên khi tất cả các hệ thống VC có thể làm điều đó. Những gì bạn cần là một tiện ích hợp nhất ba cấp độ từ, nhưng tôi không biết. (Ví dụ: TortoiseMerge và kdiff3 đều dựa trên dòng.) Một khi bạn có một tiện ích như vậy, thì bất kỳ hệ thống VC nào cho phép bạn chỉ định một tiện ích hợp nhất bên ngoài sẽ đủ. (Bao gồm svn, bzr, git, hg ...)
Maverick Woo

3
Một nguồn gây nhầm lẫn ở đây là có một thuật toán khác biệt nhị phân tích hợp (hoạt động ở mức byte riêng lẻ) được SVN sử dụng trong giao tiếp giữa máy chủ và máy khách, và cả máy chủ bên trong để giữ kho lưu trữ gọn nhẹ. Đây chỉ đơn thuần là một sự tối ưu hóa; nó không hiển thị cho người dùng và thuật toán khác biệt nhị phân có thể được áp dụng cho bất kỳ loại tệp nào. Tất cả những thứ người dùng có thể nhìn thấy (khác biệt có thể đọc được của con người, hợp nhất, giải quyết xung đột ...) xảy ra ở phía khách hàng.
Jukka Suomela

Câu trả lời:


11

Tôi đã sử dụng git để cộng tác trên một số tài liệu viết bằng latex. Bạn sẽ phải tuân thủ một số quy tắc:

  • Bắt đầu mỗi câu trên một dòng mới, latex bỏ qua các dòng mới này miễn là không có dòng trống
  • Sử dụng cùng cấu hình để định dạng (tab / dấu cách / chiều rộng văn bản tối đa)
  • Để có kết quả tốt nhất, hãy tạo tệp .gitattribut trong kho lưu trữ của bạn và thêm dòng *.tex diff=tex. Điều này làm cho diff nhận thức được cú pháp tex và dẫn đến đầu ra có ý nghĩa hơn.

Sau đó, bạn có thể sử dụng git diff --color-wordsgitk --color-wordsđể xem sự khác biệt của từ (cũng xem bài viết này Khác biệt từng từ trong Git về cách định cấu hình git để luôn sử dụng thuật toán word-diff để hiển thị nhật ký git diff / git).

Để giảm việc hợp nhất thủ công, tôi có thể khuyên bạn nên sử dụng các tệp riêng biệt cho các phần và phần phụ (tùy thuộc vào kích thước tài liệu của bạn).


Tôi sẽ xem xét làm điều này cho các tài liệu của riêng tôi, nó dường như là một cách dễ dàng để đạt được hầu hết các mục tiêu của tôi. Nhưng không phải ai cũng muốn làm việc theo cách này ...
András Salamon

2
Đối với những người ngần ngại làm việc theo cách này, bạn có thể sử dụng TortoiseGit nếu họ không thích dòng lệnh git. Nếu đó là về mỗi câu trên một phần dòng mới, miễn là không có độ rộng văn bản tối đa bắt buộc, điều này không quan trọng. (Tôi đã làm việc trên một số dự án mà không có quy tắc đó)
Davy Landman

Nhìn chung, tôi đồng ý rằng git là một lựa chọn tốt. Nhưng tại sao các tệp riêng biệt cho các phần (phụ) có thể giảm số lần hợp nhất thủ công? Tôi cũng tự hỏi làm thế nào để bắt đầu mỗi câu trên một dòng mới giúp (đôi khi các câu trộn trong quá trình chỉnh sửa).
dd1

liên quan đến các tệp tách biệt: tại thời điểm đó, tôi không hiểu chi tiết chính xác về việc hợp nhất git, vì vậy điều đó thực sự không cần thiết, nhưng vẫn được khuyến khích vì những lý do khác. Câu trên một dòng mới rất quan trọng, vì hầu hết các công cụ xung quanh git luôn hiển thị các thay đổi dòng, nếu sau đó bạn sử dụng một chiến lược khác, hãy để trình soạn thảo thực hiện ngắt dòng, mỗi khi ai đó thay đổi 1 từ trong một đoạn, bạn sẽ phải săn nó xảy ra, và trong trường hợp hợp nhất tự động: không có cách nào.
Davy Landman


4

Tôi thực sự muốn nhắc lại những người khác và đề nghị bạn ngồi xuống và vạch ra một chiến lược SVN tốt đẹp. Tôi sử dụng SVN để lưu trữ toàn bộ cấu trúc "nghiên cứu" của mình:

  • Quản lý tham chiếu JabRef
  • Tải xuống các tệp PDF
  • Bài viết

Thật tuyệt vời vì nó chứa mọi thứ, và tất nhiên cung cấp một lịch sử. Hãy cẩn thận là bạn cần máy chủ của riêng bạn. Nhưng nếu bạn có một số máy Windows hiện có (hoặc bất cứ thứ gì bạn thấy thoải mái), bạn có thể cài đặt nó đơn giản thông qua VisualSVN Server . Sau đó, bạn tạo tài khoản phù hợp cho cộng tác viên và cấp cho họ quyền truy cập vào một khu vực thích hợp (có thể là quyền truy cập đọc vào tệp bibtex JabRef của bạn và đọc / ghi vào khu vực bài viết 'đang tiến hành' được chia sẻ).

TortiseSVN có thể được sử dụng làm máy khách Windows để tương tác với SVN. Bạn cần cẩn thận về việc di chuyển / xóa tập tin và sao chép thư mục (SVN sẽ lưu trữ siêu dữ liệu bên trong các thư mục ẩn trong mỗi thư mục của bạn, vì vậy bạn phải thực hiện lệnh xóa từ bên trong SVN để thoát khỏi nó, phải mất một chút để sử dụng để, nhưng là giá trị đầu tư).

Sau đó, khi làm việc với cộng tác viên, rõ ràng họ cũng phải sử dụng SVN. Nhưng, một lần nữa, đầu tư vào học tập không phải là vô giá trị. Và thông qua một số suy nghĩ, bạn cũng có thể có nó để bạn có quyền truy cập chỉ đọc vào tệp jabref của họ (có lẽ thông qua cơ sở 'bên ngoài' trong svn).

Bằng cách này, với một chút suy nghĩ và một chút nỗ lực, bạn có thể rơi vào tình huống bạn đang chỉnh sửa tài liệu như bình thường, cam kết thay đổi hàng đêm, cập nhật vào buổi sáng và giải quyết mọi xung đột một cách dễ dàng.

Tôi thực sự khuyên bạn nên nó. Càng nhiều người thiết lập SVN của riêng họ thì càng tốt, vì nó sẽ chỉ cải thiện các tùy chọn cộng tác trong tương lai (tuy nhiên, tất nhiên, sẽ có ích nếu có lẽ có cách thiết lập kho lưu trữ khoa học theo tiêu chuẩn).

- Chỉnh sửa: Nguyên vẹn, tôi đã viết một đề xuất như vậy ở đây: Chiến lược hợp tác khoa học với LaTeX và SVN . Nó đề xuất sử dụng tính năng bên ngoài svn để cho phép cộng tác dễ dàng giữa những người có thiết lập tương tự. Hãy cho tôi biết nếu nó cần thay đổi hoặc đơn giản là không phù hợp.


4

Trong khi đọc bài viết tuyệt vời của bạn và tự tìm kiếm một giải pháp, tôi tình cờ tìm thấy tùy chọn tô màu các thay đổi ở cấp độ từ trong gitk . Tham số gitk dường như là một tính năng mới và / hoặc không có giấy tờ vì việc tự động hoàn thành không cung cấp nó và trang man gitk không liệt kê nó.
Dưới đây là các tùy chọn mà tôi tìm thấy:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Bạn có thể tìm thấy một số cuộc thảo luận về chủ đề đó để tìm kiếm gitk "diff --color-words" .

Chỉnh sửa:
Đây là những gì trông giống như ...

Sự khác biệt được tô màu ở cấp độ từ bằng cách sử dụng gitk


1

Tôi hiểu vấn đề rất tốt. Tôi đã bắt đầu sử dụng Kính vạn hoa cho diffs với git. Nó chỉ dành cho Mac nhưng các so sánh của nó hoạt động tốt hơn wdiff và nó cũng có giao diện và cập nhật trực tiếp.


2
Đối với tôi, dường như Kính vạn hoa chỉ là một công cụ tìm khác biệt dựa trên dòng, ngoài ra, làm nổi bật những thay đổi bên trong mỗi dòng. Nó không phải là một thay thế cho wdiff và bạn bè. Kính vạn hoa tạo ra các khác biệt không thể đọc được nếu bạn, ví dụ, chỉ cần lấy một đoạn văn bản và thay đổi một số ngắt dòng. Các công cụ dựa trên Wdiff chỉ đơn giản bỏ qua các thay đổi trong ngắt dòng.
Jukka Suomela
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.