題:
純文本文檔的簡單版本控制(Linux)
Dɑvïd
2014-02-21 04:20:40 UTC
view on stackexchange narkive permalink

我想為純文本文檔確定一個簡單的FOSS版本控制系統。

對於更複雜的(學術的)寫作,我很高興使用LibreOffice。但是越來越多的我發現,通常使用 ReText在Markdown中編寫更簡單的文檔(報告,演示,演講,記筆記等)非常方便。

我現在的目標是管理這些文檔的版本。一個場景可能是:起草演示文稿->在事件A交付的“完成”版本->現在重新起草->在事件B交付的交付->現在場合C出現了,為此,事件A的版本更好->為事件C拉起草稿。

所以,我的要求是:

  • 版本控制(很明顯,這是必需的!)
  • Ubuntu /薄荷友好(PPA很好)
  • 輕鬆標記/評論/標記“提交”
  • 簡單標籤/標籤瀏覽
  • 簡單標籤/標籤搜索
  • 以前版本的簡單“恢復”
  • 進行差異的可能性
  • 與不同計算機同步的可能性
  • 簡單目錄結構/層次結構docs

我知道的一個顯而易見的解決方案是使用 Git來管理版本控制(以及其他一些關於網絡)。我並不反對,並且已經在Windows和Linux(Ubuntu,Mint)上隨便使用了Github幾年了。 但是,其中的關鍵詞是“ 隨意”,這似乎有點像是從大砲到瘋子的情景。

(我也有看到了一個有關“ 無紙化辦公文件管理器”的問題,但這似乎超出了我的需求。)

可能還有其他選擇,當然還有將會是我從未聽說過的工具。感謝您對此提供的任何幫助。

這具有一個很好的問題的所有要素。但是我發現它有點問題,因為對我來說答案是:是的,您想要一個分佈式版本控制系統,任何常見的版本控制系統都可以。選擇任何Bazaar,Git,Mercurial或什至不常見的商品。我看不到差異化因素。
是的-我認為這就是為什麼我一直不願意發布(坐在這幾天后)。對我來說,關鍵問題是*如何*完成這些任務。也許這與有關git的簡單GUI的@Caleb's問題有關。因此,我認為“差異化因素”是易用性,註釋提交,拉出特定版本,看到給定版本之間存在“差異”等方面的“簡單性”等。這對我們有幫助嗎?
“易用性”是一個困難的要求,因為產品是否滿足該要求主要是意見。我認為您需要先證明傳統的版本控制系統無法勝任,然後再提出其他要求。
RCS / CVS有什麼問題?
@DVK-如果我知道“ RCS / CVS”是什麼,我將可以更好地回答這個問題。 ;)(是的,我聽說過“ Google”!)
@IraBaxter-“您需要證明傳統的版本控制系統無法完成任務”-為什麼?難道不是對我的個人技能或傾向有一些假設嗎?如果我已經概述了“請求規範”中的某些問題,請告知。但是我不確定為什麼我必須證明“傳統的版本控制系統無法勝任”:事實上,在我的帖子中我明確指出它可以,但是我仍然想知道還有哪些其他選項可用。那應該有問題嗎? (真正的問題-不誇張!)
@David:因為否則,此問題的答案僅是標準版本控制系統的列表,此時您的問題應該是“存在什麼版本控制系統(用於存儲任何類型的文檔)?”。該問題可能以這種形式回答,但對於一般案例所涵蓋的特殊情況,似乎毫無意義。
@Davïd,我認為您應該更清楚“易用性”的含義;例如:我發現unix命令外殼是完全直觀和易於使用的。我會立即推薦git來完成這項工作,因為CLI非常實用。我敢肯定,您的意見會有所不同,但是我無法理解您的“輕鬆”之處,因為您沒有寫。一些提示:GUI或CLI?基於本地還是基於網絡?如果是GUI:表達您的喜好(在“簡單”的guis上發布示例)。
我問的關於新手界面的兩個問題不應該嚇到您!這些對象針對甚至無法打開終端,不知道降價或標記是什麼的人,並且實際上並不需要版本控制功能,因為他們不得不使用推送功能來替代通過FTP上傳的功能。
三 答案:
#1
+35
Caleb
2014-02-21 16:39:42 UTC
view on stackexchange narkive permalink

是的,您應該使用 git *。

現在讓我解釋一下原因。給定問題中當前的(相當模糊的)標準,答案似乎很明顯。如果您知道更多,甚至都不會問這個問題。您已經把自己帶到懸崖的邊緣,現在您只需要哄哄就可以跳起來。 sub>

當前場景和一些歷史記錄:

基本上有三種版本控制系統:分佈式敲擊。請允許我詳細介紹該技術術語,以及每種術語的形成方式以及如何適用於您的情況。

  • 火腿-腳

    值得注意的條目*:CVS,Subversion。

    在DVCS系統席捲全球之前,出現了VCS系統。這些可以通過中央存儲庫/服務器和用戶工作區/客戶端的星型來表徵。這些是使一組程序員保持同一頁面甚至適應其他用途的必不可少的工具。一個程序員可以在多個系統中工作,並使用分支和標籤。他們節省了很多時間。但是他們天生笨拙。 它們使一些簡單的任務變得困難。首先是設置它們的開銷,需要服務器和連接它們的特定協議。然後在處理這些錯誤時您會感到痛苦。只需說這些就能完成您的用例的工作,但會帶來權衡取捨,使生活更加複雜。 p>

    值得注意的條目:RCS。

    當涉及服務器和客戶端以及身份驗證以及所有爵士樂的東西被吞沒了的“全面爆發”系統時,可以使用精簡的系統,該系統生活在自己的小泡泡中。 RCS通過避開存儲庫的想法並一次只對一個文件進行版本控制來做到這一點。您有 file.txt ,緊挨著它的是具有版本歷史記錄的 file.txt,v 。您可以在每個文件的基礎上輕鬆實例化它,並使用一些簡單的工具來處理差異,回滾時間等。

    現在,在您說“啊哈,這就是我尋找!”,請繼續閱讀,因為這不再是最簡單或推薦的方法。 輕鬆入門是以降低操作上限為代價的,幾乎可以保證遲早會限制您的風格。

  • 分佈式

    在某個時候,一群聰明的程序員認為他們已經受夠了痛苦,並說:“我們要吃蛋糕,也要吃蛋糕。”令人驚訝的是,它們成功了,並且分佈式版本控制系統誕生了。這些系統結合了兩全其美的功能-完整的版本歷史記錄就位於原始文件旁邊的本地系統上,並且能夠共享您的歷史記錄並與其他遠程存儲庫進行交互。事實證明,這樣做沒有嚴重的技術弊端。

    對於某些商店來說,最大的障礙就是靈活性。由於系統不會對您的工作方式施加任何限制,因此從迫使您擁有一定工作流程的系統進行遷移有時會很痛苦。突然,您必須對系統的工作方式進行一些思考。過去需要進行的許多操作(總是有每個人的最新資料的中央節點)已成為僅在需要時使用的事項約定,但您必須坐下來說:“這就是我們將使用此工具的方式。”

因此,請坐下並說出如何使用此工具。

出於這個答案的目的,我將堅持使用git,因為它是最高級的工具之一被廣泛採用的系統。它很容易在大多數係統上安裝(可能尚未安裝),並且提供了涵蓋幾乎所有用例的大量文檔。它也是可擴展的,並被許多第三方系統等所認可。也就是說,它不一定比它最近的競爭對手Bazaar或Mercurial具有更好的內在優勢。

  • 在Ubuntu生態系統中,您可能想給Bazaar一眼,因為Canonical將其用於所有事物,並且它將與您的環境很好地集成。他們的 launchpad服務類似於Github,但專門針對Ubuntu軟件開發而設計。如果您打算在該生態系統中玩耍,請考慮學習 bzr 而不是git,這樣一個工具既可用於您的個人世界,也可用於您所參與的生態系統。如果您不從事啟動板上協調的項目,我建議您使用git。

  • 如果您的任何同事都對Mercurial感興趣,那麼您可能要考慮使用它。這是一款功能強大的DVCS,具有優於Git的優勢。由於更簡化的數據流,通常認為某些操作速度更快。工俱全部包裝在一個二進製文件中,而不是像Git一樣被一堆單獨的(有時是多餘的)工具所破壞。它可以使用Python綁定進行擴展,並且可以構建與其緊密集成的外部系統。該範例與Git足夠相似,一旦您學習了它,就可以繞過git倉庫。最終,git是目前該領域中最受歡迎的播放器,堅持使用git可以在需要時為您提供更多的幫助。

*對所有未命名的VCS系統致歉。 CVSNT,BitKeeper,CA,CC,darcs,化石,單調,Perforce,塑料,PVCS,Star,SVK,Vault,Vesta,VSS和其他同類產品。您的名字將永遠不會被遺忘 strike>已經僅僅是一個記憶。 sub>

git 如何適合您的用例:

您提到稍微使用了Github。很好,但是您需要記住 Github不是git 。人們通常會誤以為他們提供的是通過為您託管存儲庫來進入系統的一種免費方法。實際上,他們提供的是在git之上構建的一層,部分是社交網絡和部分項目管理。對於開源社區來說,這是一件了不起的事情。他們沒有試圖成為替代系統並與市場競爭,而是巧妙地利用了一個好的工具,並開闢了一個為企業提供增值服務並同時為社區服務的市場。但是Github不是git。

Git實際上可以以更簡單的方式使用。

類似於RCS,git在本地將內容存儲在版本旁邊。明顯的區別是它是基於每個目錄而不是每個文件來完成的。

  • RCS:

      file1 .txtfile1.txt,vfile2.txtfile2.txt,v  

    每個文件的,v 文件保留文件歷史記錄的運行列表,並存儲兩個文件之間的差異每個連續的版本。

  • git:

     目錄+ file1.txt + file2.txt + .git + glob1 + glob2  

    .git文件夾中的內容實際上具有時髦的名稱,有點複雜,但是您不需要了解它。從概念上講,它所做的只是存儲目錄中各個版本之間的差異。基本上,每個glob都是每次提交時目錄外觀的圖像。很多花哨的數學運算使開銷降低了,因此只保存了增量數據。

現在,這聽起來已經很複雜了,但是您真的不需要知道任何一個。該工具集可為您跟踪所有花哨的東西。基本用法與RCS一樣簡單,但是卻為您提供了發展的空間。

入門會像這樣:

 #轉到目錄cd〜/ pathto / yourtextfiles#初始化git以跟踪該文件夾的git init  

完成。無需服務器。只有您和您的版本控製文件。除非您沒有任何文件處於監視之下,所以git實際上並未監視任何內容。 Git並不貪婪,因為它不會跟踪文件夾中的所有內容,僅跟踪您告訴它的特定內容。因此,下一步就是告訴它您要跟踪哪些文件。您剛剛進行的更改git commit -m“ initial add”

請注意,與大多數係統不同,這是一個兩步過程。在提交事物並將其作為新版本填充到存儲庫之前,必須“暫存”它們。並非每次對工作目錄所做的更改都會自動假定為您要在每次提交時保存到的內容。也許您更改了兩個文件,但只想標記一個。 file2.txt#提交給historygit commit -m“固定錯字”

請注意,對file1.txt的更改尚未 保存到存儲庫,並且尚未對file3.txt進行任何跟踪。您可以通過運行 git status 來查看先前跟踪的文件是否已撤消更改,而通過運行 git diff 可以看到這些更改是什麼。至此狀態將告訴您,您已對file1.txt進行了更改,並且目錄中存在未跟踪的file3.txt。 Diff會向您顯示自上次上載並提交文件以來對file1.txt所做的更改。

一個“陷阱”提醒您開始工作,以免被咬住。道路是-由於git的存儲庫概念是整個目錄,並且文件更改在某個時間點被視為該目錄的映像-您應考慮為不同的項目使用單獨的存儲庫。與其從“我的文檔”中製作單個存儲庫,不應該從包含某些有意義的文檔子集的目錄中創建單獨的存儲庫,無論是按主題,按格式,按項目還是按項目。當您要使用另一台計算機上的“與x相關的所有文檔”而不必在該計算機上創建過的每個文檔時,這將使您的工作更加輕鬆。 Git不允許您簽出存儲庫的子樹*,因為它全有還是全無,所以為許多緊密相關的數據集(每個目錄一個)創建許多粒度存儲庫是錯誤的。

真的,這就是基本用法。從那裡開始,幾乎可以想像得到的一切都是可能的,但是到那時,您會問的是使用問題,而不是軟件推薦問題。

*例如,Subversion允許這樣做,我已經習慣了。當我以為git允許類似的東西時,這讓我很早就被咬住了。我將所有個人文件都保存在一個大型svn存儲庫中,並且天真地認為git將取代它。吸取了教訓,我的文件最好進行分類。可用於使您脫離命令行,並直觀地表示文件的狀態。其中許多工具具有IDE風格,可以用作文檔管理的切入點,使用它們來啟動您喜歡的編輯器*,甚至使用內置的編輯器。既然您詢問了有關如何存儲文件的後端,所以我建議使用 git 作為版本管理器,但是如果您有想法,應該從此查找和使用

*當然, gvim 非常適合此用例;-) sub>

結論:

進來吧,水很好!

一個!二!三! 跳轉 strike> git init

看看那並不難。

+1。尤其享受幽默感和全面性。做得好!
**作者註:**目前尚不完整,可以將其稱為草稿答案。我仍然需要解決原始問題中的“ ___簡單做”的問題,這可能涉及顯示為什麼git比其他後端更好地處理這些情況,指向命令行的其他文檔,以及建議GUI只需點擊一下即可完成這些功能,但是我沒時間了。
確實,這仍然是一個簡短的答案,但是我認為答案已經足夠清楚地闡明了這一點,並解決了OP的擔憂。與其他工具的比較是一個很好的補充。儘管如此,要由OP決定是否採用git,而後者肯定會幫助您做出決定。
@Caleb:“如果您知道更多,您甚至都不會問這個問題。”但是我沒有!而我做到了!現在閱讀-感謝您接管您的時間。這可能證明非常有用。
@Davïd...這就是為什麼我認為這個問題準備得到答案,而不是在澄清之前就被關閉了:
我不想偏離主題太多,但是我不同意您對CVS vs RCS的評估。與RCS相比,IME CVS入門更容易,而且沒有死胡同。但我不建議今天開始的任何人使用:DCVS是必經之路。我喜歡這個答案,但您會滑一些:選擇DCVS。我也很失望您在腳註中沒有提到SCCS。
@Gilles我真的不想打開CVS蠕蟲病毒。與Subversion這樣的新興公司相比,它也具有一些優勢,並且在某些方面比RCS更簡單。我之所以選擇RCS,是因為我可以合理地簡化它,與git在概念上的工作方式形成對比,我認為這對剛起步的人來說是一個重要的對比。是的,我在_CS_DVCS上使用了躲避球。第二個答案或與本案相符的新章節可能是有條理的,但我對Mercurial並不足夠了解。 SCSS比我還早!
git確實沒有聽起來那麼可怕。另一方面,Bazzar ..很好。
SVN允許在單個子目錄上進行更改的缺點是,當我們有人在代碼樹的一部分分支中不包含該代碼的“所有依賴項”時,我們永遠無法重新創建他的發行版候選人建立。
#2
+4
VicAche
2014-04-16 17:43:13 UTC
view on stackexchange narkive permalink

在這種情況下,我建議您使用 https://draftin.com/,請參閱此處,以快速了解您可能希望使用的特定功能。 / p>

此軟件的一個缺點是我想指出,然後再給出您的問題的詳細答案是該軟件可以在線使用。可以在沒有Internet連接的情況下使用草稿(請參見此處的),但是它仍然需要完善-同步(草稿中的一項基本功能),在離線之前仍必須手動觸發。

  1. 版本控制:肯定是。它是草稿中的一項核心功能,它很棒,因為它在您不想看到它時不會妨礙您,但是每次您(或與您共享寫作的任何人)遇到麻煩時,它都會為您服務與文檔有關。 (默認情況下,您的文檔版本中不包含其他人的編輯,您必須先接受它們。)

  2. Ubuntu / Mint友好:,畢竟這是一個網站。任何降級的瀏覽器都可以解決問題,我只測試了鉻的離線功能,鉻具有適用於Ubuntu的PPA。

  3. 易於標記/註釋/標籤:。關鍵是草稿應允許您標記文檔的主要和次要版本,並明確指出誰進行了編輯,從而為您解決了這一問題。在這一點上,草稿並不是您的最佳工具。

  4. 簡單的標籤/標籤瀏覽,搜索:不確定。好吧,如果草稿標籤集至少適合您的需要。

  5. 以前版本的簡單“恢復”:。您不僅可以恢復以前的版本,還可以保留兩個版本中的有用位,並在查看與其他任何版本的差異時編輯當前版本。

  6. 進行比較的可能性:。有時候這件事會弄錯(最煩人的情況是在重寫段落時:Draftin認為我將每個句子替換為一個新句子,在diff中混合了新舊句子,而我希望將新段落與雖然比較舊,但是顏色代碼使它處理起來不那麼恐怖。)但是,差異可以很好地工作。

  7. 可以與其他計算機同步: ,因為它的網頁性質。但是,離線模式很奇怪,並且需要手動同步。

  8. 文檔的簡單目錄結構/層次結構:是,但是,有點太簡單了甚至。您可以將文檔放在文件夾中,但是我還沒有找到嵌套文件夾的方法,這是一個很大的缺點。

  9. ol>

    總而言之,草稿將其強加給用戶,如果您喜歡的話,這很酷(我喜歡)。當然,您應該嘗試一下它,但是它的靈活性很低(如果您喜歡編碼,它確實提供了API)可能會限制其範圍。

有用的回复(如果您願意,您可能有足夠的代表來編輯帶有鏈接的答案)。特別感謝您指出的“缺陷”(例如,#8),儘管它們不是“致命的”。有人以為我似乎*找不到*:是否涉及成本?似乎由Privacy&ToS暗示,但找不到任何其他信息。
我免費使用它,沒有任何限制。在打開網頁時,每次都會顯示一條小消息,讓我記住我可以支持開發人員,並給出兩種付款方式; 1.每月/每年訂閱。 2.一次性購買給您或您的朋友的禮物。禮物正在被作家審查,目的是幫助您提高寫作的舒適度。
#3
  0
mmv-ru
2017-08-01 18:41:36 UTC
view on stackexchange narkive permalink

git是版本控制的良好解決方案。

  • 研究集成在ReText中的版本控制系統支持。 (我找不到)
  • 嘗試git前端。我喜歡git-cola。
  • 嘗試使用外部差異/合併工具。我喜歡Meld。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...