LaTeX/LaTeX 文件的協作編寫
 |
此頁面需要關注。您可以幫助改進它，請求專案幫助，或檢視當前進度。 |
注意：此 Wikibook 的部分內容（關於 subversion 的部分）基於 科學 LaTeX 文件的協作編寫工具 文章，該文章由 Arne Henningsen 撰寫，並發表在 2007 年第 3 期《PracTeX 期刊》上（http://www.tug.org/pracjourn/）。
文件的協作編寫需要作者之間進行強大的同步。本 Wikibooks 描述了組織 LaTeX 文件協作準備的各種可能方法。
- 首先介紹了幾種不基於版本控制系統的方法。
- 然後討論了幾個適合協作的 latex 樣式檔案。
- 接下來介紹了一種基於版本控制系統Subversion（http://subversion.apache.org/）的解決方案。本 Wikibooks 描述瞭如何將Subversion與其他幾個軟體工具和 LaTeX 軟體包結合使用，以組織 LaTeX 文件的協作準備。
- 另一種方法是使用 mercurial https://www.mercurial-scm.org/ 和 bitbucket https://bitbucket.org/
- 您可以使用“安裝”章節中列出的線上解決方案之一。它們中的大多數都具有協作功能。
- 另一種協作選擇是 dropbox。它提供 2 GB 的免費儲存空間和版本控制系統。工作方式類似於 SVN，但更加自動化，因此對於 LaTeX 初學者特別有用。但是，Dropbox 不是真正的版本控制系統，因此不允許您將文章回滾到以前的版本。基於 Web 的編輯器 LaTeX Base 支援同步到 Dropbox。
- 您可以使用構建在版本控制系統之上的線上協作工具，例如 Authorea 或 ShareLatex。Authorea 執行本文件中描述的大多數操作，但在後臺執行（它構建在 Git 之上）。它允許作者透過具有數學符號、圖形、d3.js 圖表、IPython 筆記本、資料和表格的 GUI 輸入 LaTeX 或 Markdown。所有內容都呈現為 HTML5。Authorea 還具有評論系統和基於文章的聊天功能，以方便協作和審查。
- 由於 LaTeX 系統使用純文字，因此您可以使用同步協作編輯器，例如 Gobby。在 Gobby 中，您可以與任何人即時協作編寫文件。強烈建議您使用 utf8 編碼（尤其是在有多個作業系統上的使用者進行協作時）和穩定的網路（通常是有線網路）。
- 例項（例如 此示例中的維基媒體上的 etherpad）的 EtherPad。要編譯，請使用以下命令：
wget -O filename.tex "https://etherpad.wikimedia.org/ep/pad/export/xxxx/latest?format=txt" && (latex filename.tex)
其中“xxxx”應替換為便箋本編號（類似於“z7rSrfrYcH”）。
- 使用帶有 LaTeX 和 Dropbox 的專用 Linux 伺服器，可以結合使用 Google 文件和 一些指令碼，以便從 Google 文件的更新中自動生成 Dropbox 上的 PDF 檔案。
- 您可以使用 分散式版本控制系統，例如 Fossil、Mercurial 或 Git。對於尋求控制和高階功能（如分支和合並）的使用者來說，這是最終解決方案。與基於 Web 的解決方案相比，學習曲線會更陡峭。
- Syncthing 是跨機器同步檔案的另一種開源替代方案
工具 latexdiff 和 changebar 可以視覺化生成的文件中兩個 LaTeX 檔案的差異。這使得更容易檢視某些更改的影響或與不熟悉 LaTeX 的人討論更改。Changebar 帶有一個指令碼 chbar.sh，該指令碼在邊距中插入一個條形，指示已更改的部分。Latexdiff 支援不同的視覺化樣式。預設情況下，丟棄的文字標記為紅色，新增的文字標記為藍色。它還支援類似於 Changebar 的模式，該模式在邊距中新增一個條形。Latexdiff 帶有一個指令碼 latexrevise，可用於接受或拒絕更改。它還具有一個包裝器指令碼以支援版本控制系統，例如討論的 Subversion。
有關如何在終端中使用 Latexdiff 的示例。
latexdiff old.tex new.tex > diff.tex # Files old.tex and new.tex are compared and the file visualizing the changes is written to diff.tex pdflatex diff.tex # Create a PDF showing the changes
如果您使用 mercurial，則語法如下：latexdiff-vc --hg test.tex -r revnumber
其中 revnumber 是相關更改集的（本地）revnumber。
重要建議
有時 latexdiff 會遇到問題（生成的 latex 程式碼無法編譯）。如果存在與數學公式相關的重大更改，則可能會發生這種情況。為了解決此問題，latexdiff 提供了選項 --math-markup
--math-markup=3對數學公式的更改非常敏感。--math-markup=0忽略數學公式的更改。有關詳細資訊，請參閱文件。
程式 DiffPDF 可用於直觀地比較兩個現有的 PDF 檔案。還有一個基於 DiffPDF 的命令列工具 comparepdf。
通常情況下，對於協作來說，建議採用模組化的方法，因為它最大程度地降低了編輯衝突的風險。詳情請參閱 https://wikibook.tw/w/index.php?title=LaTeX/Modular_Documents&stable=0，建議使用子檔案，但這並不是唯一的解決方案。
todonotes.sty 允許您插入待辦事項，可以是邊注或內聯，並在文件開頭新增一個（支援超連結的）待辦事項列表。與 fixme.sty 相比，這個包的特別之處在於邊注待辦事項會用一條線指向相關的文字。此功能在 Libreoffice、MS Office 等中很常見，詳情請參閱手冊 https://ctan.org/pkg/todonotes?lang=en。
以下是一個示例
\documentclass{article}
\usepackage[colorinlistoftodos, textwidth=3cm, shadow]{todonotes}
\newcounter{ubcomment}
\newcommand{\ubcomment}[2][]{%
\refstepcounter{ubcomment}%
{%
\todo[linecolor=black,backgroundcolor={green!40!},size=\footnotesize]{%
\textbf{Fixme: UB [\uppercase{#1}\theubcomment]:}~#2}%
}}
\newcommand{\ubcommentinline}[2][]{%
\refstepcounter{ubcomment}%
{%
\todo[linecolor=black,inline,backgroundcolor={green!40!},size=\footnotesize]{%
\textbf{Fixme: UB [\uppercase{#1}\theubcomment]:}~#2}%
}}
\newcommand{\ubcommentmultiline}[2]{%
\refstepcounter{ubcomment}%
{%
\todo[linecolor=black,inline,caption={\textbf{{Fixme: UB}
[\theubcomment] #1}} ,backgroundcolor={green!40!},size=\footnotesize]{%
\textbf{Fixme: UB [\theubcomment]:}~#2}%
}}
% add support for todo in equations
\usepackage{marginnote}
\makeatletter
\renewcommand{\@todonotes@drawMarginNoteWithLine}{%
\begin{tikzpicture}[remember picture, overlay, baseline=-0.75ex]%
\node [coordinate] (inText) {};%
\end{tikzpicture}%
\marginnote[{% Draw note in left margin
\@todonotes@drawMarginNote%
\@todonotes@drawLineToLeftMargin%
}]{% Draw note in right margin
\@todonotes@drawMarginNote%
\@todonotes@drawLineToRightMargin%
}%
}
\makeatother
\begin{document}
\listoftodos
This is one example \ubcomment{Comment 1}
Now more text and an inline comment: \ubcommentinline{This is an
inline comment}.
Now even more text and a comment with an enumerate list.
\ubcommentmultiline{Third comment}{
this is not true because
\begin{enumerate}
\item Reason 1
\item Reason 2
\end{enumerate}
}
Finally a comment inside a math environment.
\begin{equation}
\label{eq:todo-example:1}
\int f dx =0 \ubcomment{are you sure this integral is zero???}
\end{equation}
\end{document}
請注意：您需要使用 pdflatex（xelatex 也適用）並執行多次，即三次或四次。
這個包 https://ctan.org/pkg/rcsinfo?lang=en（以及 rcs-multi https://ctan.org/pkg/rcs-multi）會以類似的方式自動插入當前版本、日期和檔案的擁有者，前提是該檔案受與RCS語法相容的版本控制系統的控制，例如 CVS、Subversion 和 Mercurial。（請參閱下方如何設定 Mercurial）。以下是一個示例
\documentclass[12pt]{article}
\usepackage[scrpage2]{rcsinfo}
\makeatletter \def\@rcsInfoFancyInfo{{\footnotesize%
\emph{ \fcolorbox{black}{green}{Rev: \rcsInfoRevision,}
\fcolorbox{black}{yellow}{\rcsInfoOwner,} \rcsInfoLongDate,
\rcsInfoTime}}} \makeatother
\rcsInfo $Id: main.tex,v [Hg:291] 2018/08/08 16:36:51 oub Exp oub $
\begin{document}
This is a test.
\end{document}
無論是否協作，版本控制系統對於單作者文件也很有用，因為它允許跟蹤更改並根據需要恢復舊版本。最古老且仍在使用的版本控制系統是 RCS，但它面向單個檔案，並且不基於伺服器模型。CVS 基於 RCS，但適用於多個檔案，也包含伺服器模型。在某種程度上，它被 Subversion 取代（見下文）。另一種方法是由所謂的分散式版本控制系統採用的，其中最流行的是 Git 和 Mercurial（見下文）。
系統應該允許多個使用者對系統進行讀寫訪問，類似於“伺服器”
重點不是用新版本覆蓋檔案或檔案，而是系統應該以某種形式儲存不同的版本。原因是
- 可以透過執行適當的 diff 程式來比較更改，
for example latexdiff, on different version of the file.
- 允許在必要時恢復舊版本。
順序協作是指一個使用者工作，而其他使用者什麼也不做，獲取更改，然後下一個使用者開始。
讓我們考慮一個非順序協作。（為了說明問題，示例使用了一個檔案，原則上，不同檔案在目錄中也會出現相同的問題，但不太直觀。）
- 使用者 1 想要修改檔案 1 中的第 1 節，需要 2 周時間
this modification the results is file1-modified-by-user1
- 在此期間，使用者 2 修改了檔案 1 中的第 2 節，導致
file1-modified-by-user2
- 使用者 3 修改了檔案 1 中的第 3 節，導致檔案 1-modified-by-user3
版本系統必須能夠毫無問題地“合併”這三個更改。
根據定義，編輯衝突是指發生在檔案同一行的編輯。系統應檢測到這種情況，並提供建議和解決方法。
協作編寫文件需要作者之間進行大量的協調。這種協調可以透過多種不同的方式組織，最佳方式取決於具體情況。
作者之間交換文件的方法有很多。一種可能性是透過交換電子郵件來編寫文件。這種方法的優點是普通使用者通常不必安裝和學習任何額外的軟體，因為幾乎所有作者都有電子郵件帳戶。此外，修改文件的作者可以輕鬆地附加文件並透過電子郵件解釋更改。不幸的是，當兩個或多個作者同時處理同一文件時，就會出現問題。那麼，作者如何同步這些檔案？除了這個困難之外，如果涉及多個檔案，基於電子郵件的方法很容易變得繁瑣。另一種方法是使用分散式或基於伺服器的版本控制系統。在詳細介紹之前，下一小節將概述此方法的基本要求。
第二種可能性是在大多數部門都可用的公共檔案伺服器上提供文件。可以透過鎖定當前正在編輯的檔案來消除覆蓋彼此修改的風險。但是，通常只能從部門內部訪問檔案伺服器。因此，不在大樓內的作者無法使用此方法更新/提交他們的更改。在這種情況下，他們將不得不使用其他方法來解決此問題。那麼，作者如何訪問這些檔案？
第三種可能性是使用版本控制系統。可以在 維基百科上找到版本控制系統的完整列表。版本控制系統會跟蹤專案中所有檔案的更改。如果許多作者同時修改文件，版本控制系統會嘗試自動合併所有修改。但是，如果多個作者修改了同一行，則無法自動合併修改，使用者必須透過手動決定保留哪些更改來解決衝突。作者還可以註釋他們的修改，以便合作者能夠輕鬆理解此檔案的工作流程。由於版本控制系統通常透過網際網路通訊（例如，透過 TCP/IP 連線），因此可以從具有網際網路連線的不同計算機上使用它們。限制性防火牆策略可能會阻止版本控制系統連線到網際網路。在這種情況下，需要請求網路管理員開啟相應的埠。網際網路僅用於同步檔案。因此，不需要永久的網際網路連線。版本控制系統的唯一缺點可能是需要安裝和配置。
此外，即使單個使用者正在處理專案，版本控制系統也很有用。首先，使用者可以跟蹤（並可能撤銷）所有先前的修改。其次，這是一種在其他計算機（例如，版本控制伺服器）上備份檔案的便捷方法。第三，這允許使用者輕鬆地在不同的計算機（例如，辦公室、筆記型電腦、家庭）之間切換。
作為流行的版本控制系統 CVS 的繼任者，Subversion (SVN) 應運而生。SVN 採用客戶端-伺服器模型，其中中央伺服器託管專案儲存庫，使用者可以本地複製和修改該儲存庫。儲存庫的功能類似於圖書館，允許使用者檢出當前專案，進行更改，然後檢入。伺服器會記錄使用者檢入的所有更改（通常帶有總結使用者所做更改的訊息），以便其他使用者可以輕鬆地將這些更改應用到自己的本地檔案。
每個使用者都有一個遠端儲存庫的本地工作副本。例如，使用者可以將儲存庫中的更改更新到其工作副本，將自己工作副本中的更改提交到儲存庫，或者（重新）檢視工作副本和儲存庫之間的差異。
要設定 SVN 版本控制系統，必須在具有永久網際網路訪問許可權的（單個）計算機上安裝 SVN 伺服器軟體。（如果這臺計算機沒有靜態 IP 地址，可以使用像 DynDNS 這樣的服務來透過靜態主機名訪問伺服器。）它可以在許多 Unix、現代 MS Windows 和 Mac OS X 平臺上執行。
使用者不必安裝 SVN 伺服器軟體，但需要安裝 SVN "客戶端"軟體。這是訪問伺服器上儲存庫的唯一方式。除了基本的 SVN 命令列客戶端之外，還有幾個圖形使用者介面工具 (GUI) 和外掛可用於訪問 SVN 伺服器（參見 http://subversion.tigris.org/links.html）。此外，網際網路上還有很多關於 SVN 的優秀手冊免費提供（例如 http://svnbook.red-bean.com）。
在我們部門，我們在 GNU-Linux 系統上執行 SVN 伺服器，因為大多數 Linux 發行版都包含它。從這個意義上說，安裝、配置和維護 SVN 是一項非常簡單的任務。
大多數 MS Windows 使用者透過 TortoiseSVN 客戶端訪問 SVN 伺服器，因為它為普通使用者提供了最常用的介面。Linux 使用者通常使用命令列中的 SVN 實用程式，或者使用 eSvn（一個 GUI 前端）以及 KDiff3 來顯示覆雜的差異。
在我們的Subversion伺服器上，我們有一個用於通用texmf樹的儲存庫。其結構符合TeX 目錄結構指南（TDS，http://www.tug.org/tds/tds.html，參見圖 1）。此儲存庫提供 LaTeX 類、LaTeX 樣式和 BibTeX 樣式，這些樣式在使用者的 LaTeX 發行版中不可用，例如，因為它們是在我們部門內部購買或開發的。所有使用者都有此儲存庫的工作副本，並且已配置 LaTeX 以將其用作其個人texmf樹。例如，teTeX (http://www.tug.org/tetex/) 使用者可以編輯其 TeX 配置檔案（例如/etc/texmf/web2c/texmf.cnf) 並設定變數TEXMFHOME到通用工作副本的路徑texmf樹（例如透過TEXMFHOME = $HOME/texmf)；MiKTeX (http://www.miktex.org/) 使用者可以在 MiKTeX 選項的“根”選項卡中新增通用工作副本的路徑texmf樹。
如果添加了新的類或樣式檔案（但如果修改了這些檔案則不會），則使用者必須在可以使用這些類和樣式之前更新其“檔名資料庫”（FNDB）。例如，teTeX 使用者必須執行texhash；MiKTeX 使用者必須單擊 MiKTeX 選項的“常規”選項卡中的“重新整理 FNDB”按鈕。
此外，儲存庫包含說明我們部門特定 LaTeX 軟體解決方案的手冊（例如本文件）。
Subversion伺服器為我們部門的每個專案託管一個單獨的儲存庫。儘管分支、合併和標記對於編寫文字文件不如編寫軟體原始碼重要，但我們的儲存庫佈局遵循“Subversion 手冊”的建議（http://svnbook.red-bean.com）。從這個意義上說，每個儲存庫都有三個目錄/trunk, /branches，以及/tags.
最重要的目錄是/trunk。如果單個文字文件屬於該專案，則此文字文件的所有檔案和子目錄都在/trunk中。如果專案產生兩個或多個不同的文字文件，/trunk包含每個文字文件的子目錄。文字文件的略微不同的版本（分支）（例如，用於在會議上展示）可以在/trunk的附加子目錄中或/branches的新子目錄中準備。當文字文件提交到期刊或會議時，我們在目錄/tags中建立一個標記，以便以後可以輕鬆識別文件的提交版本。此功能已被證明非常有用。建立分支和標記時，務必始終為此類操作使用Subversion客戶端（而不是本地檔案系統的工具），因為這可以節省伺服器上的磁碟空間，並保留有關這些文件相同歷史記錄的資訊。
通常會出現以下問題：哪些檔案應該放在版本控制之下。通常，使用者直接修改且編譯文件所必需的所有檔案都應包含在版本控制系統中。通常，這些是 LaTeX 原始碼（*.tex）檔案（主文件和一些子文件）以及插入文件中的所有圖片（*.eps, *.jpg, *.png，以及*.pdf檔案）。所有 LaTeX 類（*.cls）、LaTeX 樣式（*.sty）、BibTeX 資料庫（*.bib）和 BibTeX 樣式（*.bst）通常應託管在通用儲存庫中texmf樹，但如果某些（外部）合著者無法訪問通用texmf樹，則可以將其包含在相應的儲存庫中。另一方面，在編譯過程中自動建立或修改的所有檔案（例如*.aut, *.aux, *.bbl, *.bix, *.blg, *.dvi, *.glo, *.gls, *.idx, *.ilg, *.ind, *.ist, *.lof, *.log, *.lot, *.nav, *.nlo, *.out, *.pdf, *.ps, *.snm，以及*.toc檔案）或由（LaTeX 或 BibTeX）編輯器（例如*.bak, *.bib~, *.kilepr, *.prj, *.sav, *.tcp, *.tmp, *.tps，以及*.tex~檔案）通常不應該放在版本控制之下，因為這些檔案對於編譯不是必需的，並且通常不包含其他資訊。此外，這些檔案會定期修改，因此衝突的可能性非常大。
版本控制系統的一個很棒的功能是，所有作者都可以透過檢視檔案任意版本之間的差異來輕鬆跟蹤專案的流程。作者主要關注原始碼的“有效”修改，這些修改會更改編譯後的文件，而不是對編譯後的文件沒有影響的“無效”修改（例如，換行符的位置）。用於比較文字文件的軟體工具（“diff 工具”）通常無法區分“有效”和“無效”修改；它們會突出顯示這兩種型別的修改。這大大增加了查詢和審查“有效”修改的工作量。因此，應避免“無效”修改。
從這個意義上說，不無緣無故地更改換行符的位置非常重要。因此，使用者 LaTeX 編輯器的自動換行應關閉，並且應手動新增換行符。否則，如果在段落開頭新增或刪除一個單詞，則該段落的所有換行符都可能會更改，因此大多數 diff 工具會將整個段落標記為已修改，因為它們逐行比較檔案。diff 工具wdiff (http://www.gnu.org/software/wdiff/) 和dwdiff (http://os.ghalkes.nl/dwdiff.html) 不受換行符位置的影響，因為它們逐詞比較文件。但是，它們的輸出不太清晰，因此修改更難以跟蹤。此外，這些工具不能直接與Subversion命令列開關--diff-cmd一起使用，而必須使用一個小的包裝指令碼 (http://textsnippets.com/posts/show/1033)。
一個合理的約定是在每個句子後新增換行符，並在新行中開始每個新句子。請注意，這除了版本控制之外還有另一個優勢：如果您想在 LaTeX 程式碼中查詢您在編譯的（DVI、PS 或 PDF）檔案中或列印輸出上看到的句子，您可以輕鬆識別該句子的前幾個單詞，並在編輯器視窗的左邊界上篩選這些單詞。
此外，我們將長句子拆分為幾行，以便每行最多約 80 個字元，因為在長行中搜索（小）差異相當不方便。（注意：例如，LaTeX 編輯器Kile (http://kile.sourceforge.net/) 在配置為新增標記第 80 列的垂直線時可以幫助使用者完成此任務。）我們發現引入句子邏輯斷點處的額外換行符非常有用，例如，在關係從句之前或句子的新部分開始之前。符合這些指南格式的示例 LaTeX 程式碼是 Arne Henningsen 編寫的文章用於科學 LaTeX 文件協作寫作的工具的原始碼，該文章發表在The PracTeX Journal 2007 年第 3 期（http://www.tug.org/pracjourn/2007-3/henningsen/）中（包括原始碼）。
如果作者使用不同的作業系統，他們的 LaTeX 編輯器可能會以不同的換行符（行尾字元）(w:Newline）儲存檔案。為了避免這種“無效”修改，所有使用者可以商定一個特定的換行符，並配置他們的編輯器使用此換行符。另一種方法是新增 Subversion 屬性“svn:eol-style”並將其設定為“native”。在這種情況下，Subversion 會自動將該檔案的所有換行符轉換為作者作業系統本機的換行符(http://svnbook.red-bean.com/en/1.4/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style)。
減少“無效”修改的數量還有另一個重要原因：如果多個作者同時處理同一個檔案，那麼同一行被兩個或多個作者同時修改的機率會隨著修改行數的增加而增加。因此，“無效”修改會不必要地增加衝突的風險（參見文件交換部分）。
此外，版本控制系統允許使用一種非常有效的質量保證措施：所有作者都應該在將自己的修改提交到程式碼庫之前對其進行嚴格審查（參見圖 2）。使用者工作副本和程式碼庫之間的差異可以透過單個Subversion命令或圖形Subversion客戶端中的一兩下點選輕鬆檢查。此外，作者應在將修改提交到程式碼庫之前驗證其程式碼是否可以完美編譯。否則，當其他作者想要編譯文件時，他們將不得不為這些錯誤買單。然而，這條指令不僅適用於版本控制系統，也適用於所有其他在作者之間交換文件的方式。
Subversion 具有一個名為“關鍵字替換”的功能，該功能將有關檔案的動態版本資訊（例如修訂號或最後作者）包含到檔案本身的內容中（例如，參見http://svnbook.red-bean.com，第 3 章）。有時，不僅將這些資訊作為 LaTeX 原始碼中的註釋包含在內，而且還將其包含在（編譯後的）DVI、PS 或 PDF 文件中也很有用。這可以透過 LaTeX 包svn(http://www.ctan.org/tex-archive/macros/latex/contrib/svn/)、svninfo(http://www.ctan.org/tex-archive/macros/latex/contrib/svninfo/)或（優選）svn-multi(http://www.ctan.org/tex-archive/macros/latex/contrib/svn-multi/)來實現。
使用版本控制系統協作編寫 LaTeX 文件的最重要指令總結在下框中。
使用 LaTeX 與版本控制系統的指令
- 避免“無效”修改。
- 沒有充分理由不要更改換行符。
- 關閉 LaTeX 編輯器的自動換行功能。
- 在新行中開始每個新句子。
- 將長句子分成幾行，以便每行最多約 80 個字元。
- 僅將使用者直接修改的檔案置於版本控制之下。
- 在將修改提交到程式碼庫之前，驗證程式碼是否可以完美編譯。
- 在將修改提交到程式碼庫之前，使用Subversion的 diff 功能嚴格審查修改。
- 在將修改提交到程式碼庫時新增有意義且描述性的註釋。
- 使用Subversion客戶端複製、移動或重新命名受版本控制的檔案和資料夾。
如果使用者願意放棄 SVN 的內建diff實用程式並使用其工作站上的本地diff工具，他們可以使用更適合文字文件的工具。隨 SVN 附帶的diff工具的設計考慮了原始碼。因此，它被構建為對短行檔案更有用。其他工具，例如Compare It!允許方便地比較每個行可以跨越數百個字元的文字檔案（例如，當每行表示一個段落時）。當使用允許方便檢視長行檔案的diff工具時，使用者可以編寫 TeX 檔案而無需嚴格的換行策略。
如以下連結所述：https://en.wikipedia.org/wiki/Distributed_version_control：在軟體開發中，分散式版本控制（也稱為分散式修訂控制）是一種版本控制形式，其中完整的程式碼庫（包括其完整歷史記錄）會映象到每個開發人員的計算機上。這允許自動管理分支和合並，提高大多數操作的速度（除了推送和拉取），提高離線工作的能力，並且不依賴於單個位置進行備份。
軟體開發作者 Joel Spolsky 將 DVCS 描述為“可能是過去十年軟體開發技術中最大的進步”。
目前最流行的 DVCS 是
- Git https://git-scm.tw/ 和
- Mercurial https://www.mercurial-scm.org/
儘管 Git 更流行，並且可能更適合非常大型的軟體專案，但 Mercurial 有一些特性使其特別適合基於 LaTeX 的科學協作。
- 除了變更集雜湊之外，它還有一個本地修訂號，這使得處理不同的變更集更容易。
- 它具有關鍵字擴充套件功能，因此適合使用 rcs-multi.sty 和其他在文件頁尾或標題中新增版本號的 LaTeX 樣式。
- 除了書籤之外，它還有命名分支，如果需要多個分支，則命名分支更直觀。
- 它在所有已知作業系統上都能完美執行。
- GUI https://www.mercurial-scm.org/wiki/TortoiseHg 提供了一個直觀的介面。
以下說明介紹瞭如何設定 Mercurial。Git 的設定非常相似，幾乎相同，例如，參見 Git/Mercurial Rosetta Stone：https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone
有關在不同作業系統中安裝 Mercurial 的資訊，請參見：https://www.mercurial-scm.org/downloads
Mercurial 編寫並附帶了各種所謂的擴充套件，這些擴充套件必須在全域性 .hgrc 配置檔案中單獨啟用。
以下是一個示例
# example config (see "hg help config" for more info)
[ui]
username = Joe Doe <user@gmail.com>
[extensions]
churn =
# Read the documentation of how to set up the notify extension, this
# extension is not needed if you use the bitbucket notify system
# notify =
strip =
share =
progress =
eol =
hgk =
hgext.bookmarks =
interhg =
rebase =
shelve =
purge =
record =
color =
keyword =
hgext.fetch=
histedit =
# Advanced extensions
# evolve =
# hggit =
# Minimal setting for keyword expansion.
[keyword]
**.tex =
[keywordmaps]
Author = {author|user}
Date = {date|utcdate}
Header = {root}/{file},v {node|short} {date|utcdate} {author|user}
Id = {file|basename},v {rev} {date|utcdate} {author|user} Exp {author|user}
# Other options
# Id = {file|basename},v {rev}{latesttag}.{latesttagdistance} {date|utcdate} {author|user} Exp {author|user}
# the problem with this is that adding a tag increases the rev number so that
# in the latex document the string is always v4.2 or 5.2 but never v4.1.
# Id = {file|basename},v {latesttag}.{latesttagdistance}[Hg:{rev}] {date|utcdate} {author|user} Exp {author|user}
# simplified version
# Id = {file|basename},v |Brch:{branches}|{latesttag}[Hg:{rev}] {date|utcdate} {author|user} Exp {author|user}
RCSFile = {file|basename},v
RCSfile = {file|basename},v
Revision = {node|short}
Source = {root}/{file},v
[hostfingerprints]
bitbucket.org.fingerprints=sha256:ae:ca:bf:83:41:14:55:8d:ea:70:ae:06:7d:ad:c0:44:77:6f:81:1a:c9:1e:d3:ab:f5:38:98:2b:07:4b:d4:70
[color]
custom.rev = red
custom.decorate = yellow
custom.date = green
custom.author = blue bold
[eol]
native = LF
如前所述，建議使用模組化方法與 LaTeX 協作，使用 subfile 包。典型的 LaTeX 模板目錄可能如下所示
-rw-r--r-- 1 oub oub 254K Aug 7 21:15 bibfile.bib -rw-r--r-- 1 oub oub 637 Aug 14 09:21 main.tex -rw-rw-r-- 1 oub oub 576 Aug 14 09:21 sec1-main-result.tex -rw-rw-r-- 1 oub oub 576 Aug 14 09:21 sec2-proof.tex
因此，在該目錄中，必須執行以下操作（使用 Linux/macOS，MS Windows 類似）
hg init
hg addremove
hg commit -m "第一次提交"
可以選擇新增一個 .hgignore 檔案，對於 LaTeX，它可能如下所示
syntax: glob
*.aux
*.toc
*.mw
*.backup
*.brf
*.tdo
*.bbl
*.blg
*.bib
*.el
*.log
*.dvi
*.nav
*.pdf
*.glo
*.idx
*.ilg
*.ind
*.nlo
*.nls
*.out
*.synctex.gz
hg addremove
hg commit -m "新增 .hgignore"
因此，目錄將如下所示
drwxrwxr-x 11 oub oub 4.0K Aug 14 09:15 .. -rw-r--r-- 1 oub oub 254K Aug 7 21:15 bibfile.bib drwxr-xr-x 4 oub oub 4.0K Aug 14 09:34 .hg -rw-r--r-- 1 oub oub 215 Aug 14 09:31 .hgignore -rw-r--r-- 1 oub oub 630 Aug 14 09:34 main.tex -rw-rw-r-- 1 oub oub 568 Aug 14 09:34 sec1-main-result.tex -rw-rw-r-- 1 oub oub 562 Aug 14 09:34 sec2-proof.tex
現在，您可以設定一個空的 Bitbucket 程式碼庫並邀請協作者。
我建議使用託管的 Mercurial 程式碼庫，例如 Bitbucket。對於學術使用者，Bitbucket 提供了更慷慨的使用方式（例如，對協作者數量沒有限制）。因此，建議的方法是所有協作者都開通 Bitbucket 帳戶。
- 然後，其中一位作者將擔任維護者，建立程式碼庫並將模板作為第一個版本推送。Bitbucket 網站提供了很好的解釋，但請參見下面的詳細資訊。
- 他與其他協作者共享程式碼庫。
- 建議所有協作者都設定 Bitbucket 通知系統。
- 協作者克隆程式碼庫：例如 hg clone https://bitbucket.org/user/project1。
- 協作者編輯檔案，提交，例如
hg commit -m "新增引言" - 然後他們推送
hg push - 其他協作者會收到推送通知並拉取：
hg pull -u
但是，截至 2020 年 8 月 1 日，Mercurial 已停止透過 Mercurial 進行訪問。有兩個替代方案
- 1 保留 Mercurial 但使用 hg-git 外掛。即使對於命名分支，這也是可能的，但需要一些調整。
- 切換到 Helix，此服務提供的資源略少，但仍提供免費程式碼庫（每個帳戶 1 GB 免費空間 + 5 個協作者）。(https://info.perforce.com/try-perforce-helix-teamhub-free)
此內容複製自 Bitbucket 網站。
- 步驟 1：切換到您的程式碼庫目錄
cd /path/to/your/repo
- 步驟 2：將您現有的倉庫連線到 Bitbucket
hg push https://user@bitbucket.org/user/test
- 步驟 3：使用其新 URL 更新倉庫 .hgrc 檔案的預設欄位
[paths] default = https://user@bitbucket.org/user/test
簡而言之，大多數協作者（維護者除外）需要學習的命令是：
- hg clone https://bitbucket.org/user/project1
- hg commit -m "提交資訊"
- hg push
- hg pull -u
建議在 push 之前**始終**執行 pull 操作。
然後可能會發生兩種情況。
- 一種是沒有任何變化，上游沒有更改。
在這種情況下
hg log -G
看起來像
@ changeset: 1:cd6ae8660e6f
| tag: tip
| user: Joe Doe <user@gmail.com>
| date: Thu Aug 09 22:17:47 2018 +0200
| summary: My second commit
|
o changeset: 0:cb0b44f99bd2
- 上游存在您已拉取的更改，在這種情況下，您現在有一個新的 head，您應該將其合併。
所以在第二種情況下
hg log -G
看起來像
o changeset: 2:05548327a272
| tag: tip
| parent: 0:cb0b44f99bd2
| user: John Smith <user2@gmail.com>
| date: Thu Aug 09 22:17:22 2018 +0200
| summary: My second commit
|
| @ changeset: 1:cd6ae8660e6f
|/ user: Joe Doe <user@gmail.com>
| date: Thu Aug 09 22:17:47 2018 +0200
| summary: My second commit
|
o changeset: 0:cb0b44f99bd2
所以您應該合併
hg merge -r 2 並獲得
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
所以 hg log -G
給出
@ changeset: 3:df2f1f46a80c
|\ tag: tip
| | parent: 1:cd6ae8660e6f
| | parent: 2:05548327a272
| | user: Joe Doe <user@gmail.com>
| | date: Thu Aug 09 22:20:44 2018 +0200
| | summary: Merged successfully
| |
| o changeset: 2:05548327a272
| | parent: 0:cb0b44f99bd2
| | user: John Smith <user2@example.com>
| | date: Thu Aug 09 22:17:22 2018 +0200
| | summary: My second commit
| |
o | changeset: 1:cd6ae8660e6f
|/ user: Joe Doe <user@gmail.com>
| date: Thu Aug 09 22:17:47 2018 +0200
| summary: My second commit
|
o changeset: 0:cb0b44f99bd2
衝突更改集的合併應留給維護者處理。
有幾種可用的選項
- Overleaf（以及現在是 Overleaf 一部分的 ShareLaTeX）是一個基於 Web 的即時協作編輯器
- BlueLatex 是一個用 Scala 編寫的基於 Web 的即時協作編輯器
- Cocalc（以前稱為 SageMathCloud）有一個協作 LaTeX 編輯器
- Authorea 是一個基於 Web 的即時協作編輯器
- Papeera 是一個基於 Web 的即時協作編輯器
這種方法的優點是不需要額外的軟體，缺點是不能輕鬆使用自己喜歡的 LaTeX 編輯器。因此，幾乎所有這些服務都允許透過 Git 訪問（為此需要安裝 Git 或 Mercurial + hg-git 外掛）。
幾年前，這些服務幾乎都是免費的；現在，只有非常基本的功能是免費的，下表對此進行了更詳細的說明。
| 名稱 | 協作者 | 文件 | 透過 Git（或 Mercurial）訪問 |
| Authorea | 無限制 | 僅限 3 個文件免費 | 是 |
| Overleaf | 僅限一位作者 | 無限制 | 是 |
| Papeeria | 無限制 | 無限制 | 僅限公共倉庫 |
| 在免費版本中 |
撰寫科學文章、報告和書籍需要引用所有相關來源。BibTeX 是一個用於引用參考文獻和建立參考文獻的優秀工具（Markey 2005，Fenn 2006）。許多不同的 BibTeX 樣式可以在 CTAN (http://www.ctan.org) 和 LaTeX 參考文獻樣式資料庫 (http://jo.irisson.free.fr/bstdatabase/) 上找到。如果找不到合適的 BibTeX 樣式，可以使用 custombib/makebst (http://www.ctan.org/tex-archive/macros/latex/contrib/custom-bib/) 方便地組裝大多數所需的樣式。此外，BibTeX 樣式檔案可以手動建立或修改；但是此操作需要了解 BibTeX 樣式檔案中使用的（未命名）字尾棧語言（Patashnik 1988）。
在我們系，我們有一個通用的 BibTeX 格式的參考文獻資料庫（.bib 檔案）。它位於我們的公共texmf樹中（參見“在 Subversion 中託管 LaTeX 檔案”部分）的子目錄/bibtex/bib/（參見圖 1）。因此，所有使用者只需使用檔名（無需完整路徑）即可指定此參考文獻——無論使用者公共texmf樹的工作副本位於何處。
所有使用者都使用圖形化 BibTeX 編輯器 JabRef (http://www.jabref.org) 編輯我們的參考文獻資料庫。由於 JabRef 是用 Java 編寫的，因此它可以在所有主要作業系統上執行。由於不同版本的 JabRef 通常以略微不同的方式儲存檔案（例如，在不同位置引入換行符），因此所有使用者都應使用相同（例如，最新穩定）版本的 JabRef。否則，不同版本的.bib檔案之間將存在許多差異，這些差異僅僅源於使用不同版本的 JabRef。因此，很難找到比較文件之間的真實差異。此外，衝突的可能性會大大提高（參見“Subversion 真正發揮了作用”部分）。由於 JabRef 使用作者作業系統中的本地換行符儲存 BibTeX 資料庫，因此建議新增 Subversion 屬性“svn:eol-style”並將其設定為“native”（參見“Subversion 真正發揮了作用”部分）。
JabRef 非常靈活，可以在許多細節方面進行配置。我們對 JabRef 的預設配置進行以下更改以簡化我們的工作。首先，我們指定 BibTeX 鍵的預設模式，以便 JabRef 可以自動以我們所需的格式生成鍵。這可以透過選擇選項→首選項→鍵模式並在欄位中修改所需的模式預設模式。例如，我們使用[auth:lower][shortyear]以獲取第一個作者姓氏的小寫形式和出版年份的後兩位數字（參見圖 3）。
其次，我們新增 BibTeX 欄位位置以獲取有關出版物以硬複製形式（例如，書籍或文章副本）提供的地址資訊。此欄位可以包含擁有硬複製的使用者姓名及其位置或圖書館的名稱和書架號。可以透過選擇 JabRef 中的選項→設定通用欄位並在以位置（使用分號（;）作為分隔符）通用（參見圖 4）。
第三，我們將所有出版物的 PDF 檔案放在檔案伺服器中的特定子目錄中，在該目錄中我們使用 BibTeX 鍵作為檔名。我們透過選擇 JabRef 中的選項→首選項→外部程式並在欄位中新增此子目錄的路徑來告知 JabRef 此子目錄主要 PDF 目錄（參見圖 5）。如果出版物的 PDF 檔案可用，則使用者可以按 JabRef 的自動按鈕（位於 JabRef 的Pdf欄位左側）來自動新增 PDF 檔案的檔名。現在，所有可以訪問檔案伺服器的使用者只需點選 JabRef 的 PDF 圖示即可打開出版物的 PDF 檔案。
如果我們將專案的 LaTeX 原始碼傳送到期刊、出版商或其他無法訪問我們的公共texmf樹的人員，我們不會包含整個參考文獻資料庫，而是使用 Perl 指令碼 aux2bib (http://www.ctan.org/tex-archive/biblio/bibtex/utils/bibtools/aux2bib) 提取相關的條目。
本華夏公益教科書描述了一種有效組織 LaTeX 文件協作準備的可能方法。提出的解決方案基於 Subversion 版本控制系統以及其他一些軟體工具和 LaTeX 包。但是，仍然有一些問題可以改進。
首先，我們計劃所有使用者都安裝相同的 LaTeX 發行版。由於 TeX Live 發行版 (http://www.tug.org/texlive/) 同時適用於 Unix 和 MS Windows 作業系統，因此我們將來可能會建議使用者切換到此 LaTeX 發行版。（目前，我們的使用者有不同的 LaTeX 發行版，它們提供不同的 LaTeX 包選擇和某些包的不同版本。我們透過在我們的公共texmf樹上提供一些包來解決此問題。）
其次，我們考慮簡化通用參考文獻資料庫的解決方案。目前，它基於版本控制系統 Subversion、圖形化 BibTeX 編輯器 JabRef 和用於資料庫中出版物 PDF 檔案的檔案伺服器。對於不經常使用這些工具的使用者和不熟悉這些工具的使用者來說，使用三種不同的工具來完成一項任務是相當具有挑戰性的。此外，檔案伺服器只能由本地使用者訪問。因此，我們考慮實現一個整合的伺服器解決方案，如 WIKINDX (http://wikindx.sourceforge.net/)、Aigaion (http://www.aigaion.nl/) 或 refBASE (http://refbase.sourceforge.net/)。使用此解決方案只需要一臺有網際網路連線的計算機和一個 Web 瀏覽器，這使得不經常使用資料庫的使用者更容易使用。此外，儲存的 PDF 檔案不僅可以在系內訪問，而且可以在全球範圍內訪問。（根據儲存的 PDF 檔案的版權，對伺服器的訪問——或者至少對 PDF 檔案的訪問——必須限制在系內成員。）我們系內甚至非 LaTeX 使用者也可能受益於基於伺服器的解決方案，因為它應該更容易在（其他）文字處理軟體包中使用此參考文獻資料庫，因為這些伺服器不僅以 BibTeX 格式提供資料，還以其他格式提供資料。
歡迎所有讀者透過新增更多提示或想法或提供更多 LaTeX 文件協作寫作問題的解決方案來為本華夏公益教科書做出貢獻。
Arne Henningsen 感謝 Francisco Reinaldo 和 Géraldine Henningsen 的評論和建議，這些建議幫助他改進和闡明瞭本文，感謝 Karsten Heymann 在 LaTeX、BibTeX 和 Subversion 方面的許多提示和建議，以及 Christian Henning 及其同事支援他在他們部門建立 LaTeX 和 Subversion 的意願。
- Fenn，Jürgen (2006)：使用 BibTeX 管理引用和參考文獻。PracTEX 雜誌，第 4 期。 http://www.tug.org/pracjourn/2006-4/fenn/。
- Markey，Nicolas (2005)：馴服 BeaST。BibTeX 的 B 到 X。 http://www.ctan.org/tex-archive/info/bibtex/tamethebeast/ttb_en.pdf。版本 1.3。
- Oren Patashnik。BibTeX 樣式設計。 http://www.ctan.org/tex-archive/info/biblio/bibtex/contrib/doc/btxhak.pdf。