Domanda:
Controllo delle versioni semplice per documenti di testo normale (Linux)
Dɑvïd
2014-02-21 04:20:40 UTC
view on stackexchange narkive permalink

Vorrei identificare un semplice sistema di controllo della versione FOSS per documenti di testo normale.

Per una scrittura più complessa (accademica), uso felicemente LibreOffice. Ma sempre più trovo conveniente scrivere documenti più semplici (rapporti, presentazioni, lezioni, prendere appunti, qualunque cosa) in Markdown, di solito utilizzando ReText.

Il mio obiettivo ora è quello di gestire le versioni di questi documenti. Uno scenario potrebbe essere: stesura di una presentazione -> versione "finita" consegnata all'evento A -> ora riscritta -> consegnata all'evento B -> ora arriva l'occasione C, per la quale la versione dell'evento A è la migliore -> tirato e redatto per l'evento C.

Quindi, i miei requisiti sono:

  • controllo della versione (essenziale, ovviamente!)
  • Ubuntu / Mint friendly (PPA sarebbe fantastico)
  • facile tagging / commenting / etichettatura di "commit"
  • semplice navigazione tag / etichetta
  • semplice ricerca tag / etichetta
  • semplice "ripristino" delle versioni precedenti
  • possibilità di fare differenze
  • possibilità di sincronizzazione su macchine differenti
  • semplice struttura di directory / gerarchia per docs

Una soluzione ovvia di cui sono a conoscenza sarebbe quella di utilizzare Git per gestire il controllo della versione (e una serie di altri commenti sul ragnatela). Non sono totalmente contrario e ho usato Github casualmente sia da Windows che da Linux (Ubuntu, Mint) per alcuni anni. Ma la parola chiave che c'è è " casualmente " e sembra un po 'uno scenario da mazza da matto.

(Ho anche visto la domanda su un " Gestore documenti per uffici senza carta", ma sembra andare ben oltre le mie esigenze.)

Potrebbero esserci altre opzioni là fuori, e sicuramente ci sono saranno strumenti di cui non ho mai sentito parlare. Grato per qualsiasi aiuto con questo.

Questo ha tutti gli elementi di una buona domanda. Eppure lo trovo un po 'problematico, perché per me la risposta è: sì, vuoi un sistema di controllo delle versioni distribuito e uno qualsiasi di quelli comuni andrà bene. Scegli tra Bazaar, Git, Mercurial o anche quelli meno comuni. Non vedo un fattore di differenziazione.
Sì, penso che sia per questo che ho esitato a postare (sono stato seduto su questo un paio di giorni). Per me, la questione chiave è * come * queste attività vengono eseguite. Forse questo si riferisce alle domande di @Caleb's su semplici GUI per git. Quindi suppongo che il "fattore di differenziazione" sia la facilità d'uso, la "semplicità" nel commentare un commit, tirare una versione particolare, vedere un "diff" tra le versioni date, ecc. Questo ci porta da qualche parte?
"facilità d'uso" è un requisito difficile, perché se un prodotto soddisfa tale requisito è principalmente opinione. Penso che sia necessario dimostrare che un sistema di controllo delle versioni convenzionale non funziona, prima di chiedere qualcos'altro.
Cosa c'è di sbagliato in RCS / CVS?
@DVK - se sapessi cos'è "RCS / CVS", sarei in una posizione migliore per rispondere a questa domanda. ;) (E sì, ho sentito parlare di "Google"!)
@IraBaxter - "è necessario dimostrare che un sistema di controllo delle versioni convenzionale non funziona" - perché? Questo non fa alcune supposizioni sulle mie capacità personali o sulle mie inclinazioni? Se c'è qualcosa nelle "specifiche della richiesta" che ho delineato che è un problema, dillo. Ma non sono sicuro del motivo per cui dovrei dimostrare che "un sistema di controllo delle versioni convenzionale non funziona": nel mio post chiarisco che * può *, in effetti, ma che mi interessa ancora sapere quali altre opzioni sono disponibili. Dovrebbe essere problematico? (Domanda autentica, non retorica!)
@David: Perché altrimenti la risposta a questa domanda è solo l'elenco dei sistemi di controllo della versione standard, a quel punto la tua domanda dovrebbe essere "Quali sistemi di controllo della versione esistono (per memorizzare qualsiasi tipo di documento)?". Potrebbe valere la pena rispondere a tale domanda in quella forma, ma sembrerebbe inutile rispondere per casi speciali coperti dal caso generale.
@Davïd Penso che dovresti chiarire cosa intendi per "facilità d'uso"; Ad esempio: trovo che la shell dei comandi unix sia totalmente intuitiva e facile da usare. Consiglierei immediatamente git per questo lavoro perché la CLI è molto pratica. Sono abbastanza certo che la tua opinione sarà diversa ma non ho la possibilità di capire cosa sia "facile" per te, perché non l'hai scritto tu. Alcuni suggerimenti: GUI o CLI? Locale o in rete? Se GUI: esprimi ciò che ti piace (posta esempi su guis "facile").
Le due domande che ho posto sulle interfacce per principianti non dovrebbero spaventarti! Questi sono rivolti a persone che non possono nemmeno aprire un terminale, non avrebbero idea di cosa sia il markdown o il markup e non hanno effettivamente bisogno delle funzionalità di controllo della versione così tanto quanto devono utilizzare la funzione push in sostituzione del caricamento tramite FTP .
Tre risposte:
#1
+35
Caleb
2014-02-21 16:39:42 UTC
view on stackexchange narkive permalink

Sì, dovresti usare git*.”

Ora lascia che ti spieghi il motivo. Dato l'attuale (piuttosto nebuloso) insieme di criteri nella tua domanda, la risposta sembra abbastanza ovvia. Se ne sapessi di più, non ti faresti nemmeno questa domanda. Ti sei già portato sull'orlo della scogliera, ora devi solo convincere per fare il salto.

* O bazaar, mercurial o altri DVCS a seconda dell'attrezzatura front-end che preferisci, per essere spiegato.

La scena attuale e un po 'di storia:

Esistono fondamentalmente tre tipi di sistemi di controllo della versione: distribuiti , pugno di prosciutto e tappato . Consentitemi di espandere questa terminologia tecnica e come ciascuna di esse è nata e si applicherebbe alla vostra situazione.

  • pugno di ferro

    Voci importanti *: CVS, Subversion.

    Prima che i sistemi DVCS prendessero d'assalto il mondo, c'erano i sistemi VCS. Questi potrebbero essere caratterizzati da un repository / server centrale e uno schema a stella di spazi di lavoro / client dell'utente. Questi erano uno strumento di valore indispensabile per mantenere un team di programmatori sulla stessa pagina e persino per adattarsi ad altri usi. Un singolo programmatore potrebbe lavorare da più sistemi e giocare con rami e tag. Hanno risparmiato molti giorni. Ma erano intrinsecamente goffi. Rendono alcune semplici attività più difficili . Prima c'era il sovraccarico di configurarli, la necessità di un server e di protocolli specifici per connetterli. Poi c'era il dolore di affrontare quelle volte che hai fatto qualcosa di sbagliato. Basti dire che questi porterebbero a termine il lavoro per il tuo caso d'uso, ma introdurrebbero dei compromessi che renderebbero la vita più complicata.

  • sfruttato

    Voce degna di nota: RCS.

    Perché quando un sistema "in piena regola" che coinvolgeva server e client e autenticazione e tutto quel jazz era troppo da ingoiare, era possibile utilizzare un sistema ridotto che viveva nella sua piccola bolla. RCS lo ha fatto evitando l'idea di un repository e controllando solo un file alla volta. Avevi file.txt e accanto ad esso c'era un file.txt, v con la cronologia delle versioni. Puoi crearne facilmente un'istanza per file e utilizzare una manciata di semplici strumenti per lavorare con differenze, ripristinare il tempo, ecc.

    Ora prima di dire "Ah ah, è proprio quello che ero cercando! ", continua a leggere perché questo non è più il modo più semplice o consigliato per farlo. L'accesso facile è arrivato al costo di un tetto operativo basso che è praticamente garantito per limitare il tuo stile prima o poi.

  • distribuito

    Ad un certo punto un gruppo di programmatori intelligenti ha deciso di averne avuto abbastanza del dolore e ha detto: "Mangeremo la torta e la mangeremo anche noi". Sorprendentemente, hanno avuto successo e sono nati sistemi di controllo della versione distribuiti. Questi sistemi combinano il meglio di entrambi i mondi: cronologia completa delle versioni che si trova sul tuo sistema locale accanto ai file originali, oltre alla possibilità di condividere la tua cronologia e interagire con quella di altri repository remoti. Risulta che non ci sono seri svantaggi tecnici nel fare questo.

    L'ostacolo più significativo per alcuni negozi si è rivelato essere la flessibilità. Poiché i sistemi non impongono restrizioni arbitrarie al modo in cui lavori, a volte è doloroso migrare da un sistema che ti obbliga ad avere un determinato flusso di lavoro. All'improvviso devi pensare un po 'a come vuoi che il tuo sistema funzioni. Molte cose che prima erano richieste (nodo centrale che contiene sempre le ultime novità di tutti) sono diventate una convenzione di materia da usare solo quando lo si desidera, ma devi sederti e dire: "Questo è il modo in cui useremo questo strumento".

Quindi sediamoci e diciamo come voi usereste questo strumento.

Ai fini di questa risposta mi atterrò a git perché è uno dei più sistemi ampiamente adottati. È facile da installare sulla maggior parte dei sistemi (nella remota possibilità che non sia già installato) ed è disponibile un'ampia gamma di documentazione che copre quasi tutti i casi d'uso. È anche estensibile e riconosciuto da molti sistemi di terze parti, ecc. Detto questo, non è necessariamente intrinsecamente migliore della concorrenza più vicina, Bazaar o Mercurial.

  • Se vivi in ​​un Ecosistema Ubuntu, potresti dare un'occhiata a Bazaar perché Canonical lo usa per tutto e si integrerà bene con il tuo ambiente. Il loro servizio launchpad è simile a Github, ma adattato allo sviluppo del software Ubuntu. Se hai intenzione di giocare in quell'ecosistema, prendi in considerazione l'apprendimento di bzr invece di git in modo che uno strumento funzioni sia per il tuo mondo personale che per l'ecosistema a cui partecipi. Se non lavori su progetti coordinati su launchpad , Suggerirei di usare git.

  • Se qualcuno dei tuoi colleghi è appassionato di Mercurial, potresti voler provare a usarlo. È un DVCS molto capace con alcuni vantaggi rispetto a Git. È spesso ritenuto più veloce per alcune operazioni a causa di un flusso di dati più snello. Gli strumenti sono tutti racchiusi in un unico binario piuttosto che essere raggruppati insieme da un gruppo di strumenti separati (e talvolta ridondanti) come Git. È estensibile utilizzando collegamenti Python ed è possibile costruire sistemi esterni che si integrano molto strettamente con esso. Il paradigma è abbastanza simile a Git che una volta appreso sarai anche in grado di aggirare un repository git. Alla fine, tuttavia, git è il giocatore più popolare sul campo in questo momento e mantenerlo ti darà un accesso più pronto ad aiutare quando ne avrai bisogno.

* Mi scuso con tutti i sistemi VCS non nominati. CVSNT, BitKeeper, CA, CC, darcs, Fossil, Monotone, Perforce, Plastic, PVCS, Star, SVK, Vault, Vesta, VSS e una litania di altri. I tuoi nomi non saranno mai dimenticati sono già solo un ricordo.

In che modo git si adatta al tuo caso d'uso:

Hai menzionato di aver usato un po 'Github. È fantastico, ma devi tenere presente che Github non è git . È una percezione sbagliata comune che ciò che stanno offrendo sia un modo gratuito per entrare nel sistema ospitando i tuoi repository per te. In realtà ciò che offrono è uno strato costruito su git che è in parte social networking e in parte project management. Questa è un'ottima cosa per la comunità open source. Invece di cercare di essere un sistema alternativo e combattere il mercato, hanno brillantemente sfruttato un buon strumento e ritagliato un mercato che fornisce un servizio a valore aggiunto per le aziende e allo stesso tempo al servizio della comunità. Ma Github non è git.

Git può, infatti, essere usato in modo molto più semplice.

Simile a RCS, git memorizza le informazioni sulla versione localmente proprio accanto al tuo contenuto. La differenza notevole è che lo fa per directory piuttosto che per file.

  • RCS:

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

    Il file , v per ogni file mantiene un elenco in esecuzione della cronologia file, memorizzando il delta tra ogni versione consecutiva.

  • git:

      directory + file1.txt + file2.txt + .git + glob1 + glob2  

    Le cose nella cartella .git in realtà hanno nomi strani ed è un po 'complicata, ma non è necessario che tu lo sappia. Concettualmente tutto ciò che sta facendo è memorizzare le differenze tra le versioni di cose nella tua directory. Fondamentalmente ogni glob è un'immagine di come appariva la tua directory al momento di ogni commit. Un sacco di calcoli matematici tengono bassi i costi generali in modo che vengano salvati solo i dati delta.

Ora questo può sembrare già complesso, ma davvero non è necessario saperlo niente di tutto ciò. Il set di strumenti tiene traccia di tutte le cose fantasiose per te. L'utilizzo di base è facile come RCS ma ti dà spazio per crescere lungo la strada.

Per iniziare sarebbe qualcosa del genere:

  # Cambia nella directory che contiene i file che vuoi version.cd ~ / pathto / yourtextfiles # Inizializza git per tenere traccia di quella cartella init iniz  

Fatto. Nessun server necessario. Solo tu e i tuoi file controllati dalla versione. Tranne che non hai ancora alcun file sotto sorveglianza, quindi git in realtà non sta guardando nulla. Git non è avido nel senso che non tiene traccia di tutto in una cartella, solo delle cose specifiche a cui le dici. Quindi il passo successivo è dirgli quali file vuoi monitorare.

  # Aggiungi alcuni file al sistema, supponendo che questi esistano già nella tua dirgit aggiungi file1.txt file2.txt # Conferma il cambia semplicemente madegit commit -m "initial add"  

Nota che a differenza della maggior parte dei sistemi, questo è un processo in due fasi. Prima di eseguire il commit delle cose e inserirle nel repository come una nuova versione, è necessario "metterle in scena". Non si presume automaticamente che tutte le modifiche apportate alla directory di lavoro siano qualcosa in cui si desidera salvare con ogni commit. Forse hai cambiato due file ma vuoi solo contrassegnarne uno.

  # Modifica un gruppo di filesvim file1.txtvim file2.txtvim file3.txt # Segna solo uno di loro come il prossimo commitgit add file2.txt # Inseriscilo in historygit commit -m "fixed typo"  

Nota che le modifiche a file1.txt non sono ancora state salvate nel repository e file3.txt non è ancora tracciato. Puoi vedere che un file tracciato in precedenza ha modifiche non organizzate eseguendo git status e quali sono queste modifiche eseguendo git diff . Se questo punto lo stato ti dirà che hai apportato modifiche a file1.txt e che c'è un file3.txt non tracciato nella tua directory. Diff ti mostrerebbe le modifiche che hai apportato a file1.txt dall'ultima volta che lo hai messo in scena e messo in commit.

Un "gotcha" che dovresti essere avvertito di iniziare in modo da non morderti La strada è che, poiché il concetto di repository di git è un'intera directory e le modifiche ai file sono viste come un'immagine di quella directory in un determinato momento, dovresti considerare di avere repository separati per progetti disparati. Piuttosto che creare un unico repository da "Documenti", dovresti creare repository separati da directory che contengono qualche sottoinsieme significativo dei tuoi documenti, sia per argomento o per formato o per progetto o altro. Questo renderà più facile lungo la strada quando si desidera lavorare con "tutti i documenti relativi a x" da un'altra macchina senza dover avere tutti i documenti che hai mai creato su quella macchina. Git non consente di estrarre un sottoalbero di un repository *, è tutto o niente, quindi sbagli nel creare molti repository granulari per set di dati strettamente correlati, uno per directory.

In realtà questo è tutto ciò che serve per l'utilizzo di base. Da lì, quasi tutto ciò che puoi immaginare di fare è possibile, ma a quel punto faresti una domanda sull'utilizzo, non una domanda di raccomandazione sul software.

* Subversion, ad esempio, lo permetteva e mi ci sono abituato. Questo mi ha colpito all'inizio quando pensavo che git avrebbe permesso qualcosa di simile. Avevo TUTTI i miei file personali in un grande repository svn e ingenuamente presumo che git sarebbe stato un sostituto per quello. La lezione imparata e i miei file sono i migliori per essere classificati.

Ma i prompt dei comandi fanno paura!

Ci sono, ovviamente, una moltitudine di GUI front-end disponibile per tenerti fuori dalla riga di comando e rappresentare visivamente cosa sta succedendo con i tuoi file. Molti di questi hanno un sapore IDE e potrebbero servire come punto di ingresso nella gestione dei documenti, utilizzandoli per avviare il tuo editor preferito * o persino usarne uno integrato. Dato che hai chiesto informazioni sul back-end su come archiviare i tuoi file, ho consigliato di utilizzare git come gestore delle versioni, ma se hai in mente un modo in cui dovrebbe apparire e funzionare da una prospettiva front-end, dovresti chiederla come domanda separata.

* Ovviamente gvim sarebbe adatto per questo caso d'uso ;-)

In conclusione:

Avanti, l'acqua va bene!

Uno! Due! Tre! Jump git init .

Vedi che non è stato così difficile.

+1. Particolarmente apprezzato il sottile senso dell'umorismo e la vasta completezza. Buon lavoro!
** Nota dell'autore: ** Questo è attualmente incompleto, chiamiamolo una bozza di risposta. Devo ancora affrontare i problemi di "semplice esecuzione di ___" dalla domanda originale e questo probabilmente comporterà la dimostrazione del motivo per cui git gestirà quei casi meglio di altri back-end, indicando altra documentazione per la riga di comando e suggerendo una GUI questo fa sì che quelle funzioni puntino e clicchino, ma ho esaurito il tempo.
In effetti, è ancora "breve", ma penso che la risposta chiarisca abbastanza bene il punto e affronti le preoccupazioni del PO. Un confronto con altri strumenti è comunque una buona aggiunta. Tuttavia, spetta all'OP decidere se adotterà git e quest'ultimo sicuramente aiuterà con la decisione.
@Caleb: "Se tu sapessi di più, non ti faresti nemmeno questa domanda." Ma io no! E l'ho fatto! E ora leggo - grazie per il tempo che hai dedicato. Questo potrebbe rivelarsi molto utile.
@Davïd ... ecco perché ho pensato che la domanda fosse pronta per ottenere una risposta piuttosto che essere chiusa in attesa di chiarimenti :)
Non voglio allontanarmi troppo dall'argomento, ma non sono d'accordo con la tua valutazione di CVS rispetto a RCS. IME CVS è più facile da usare rispetto a RCS ed è meno un vicolo cieco. Ma non lo consiglierei a nessuno a partire da oggi: DCVS è la strada da percorrere. Mi piace questa risposta, ma tu hai puntato la parte scivolosa: scegliere un DCVS. Sono anche deluso dal fatto che non menzioni SCCS nella tua nota a piè di pagina.
@Gilles Non volevo davvero aprire il barattolo di worm che è CVS. Ha alcuni vantaggi anche rispetto ai nuovi arrivati ​​come Subversion e per alcune cose è più semplice di RCS. Ho scelto di esporre RCS solo perché potevo ragionevolmente semplificarlo eccessivamente in contrasto con il funzionamento di "git" a livello concettuale che pensavo fosse un contrasto importante per qualcuno che ha appena iniziato. E sì, ho giocato a dodge-ball su _ quale_ DVCS usare. Una seconda risposta o una nuova sezione qui che tratta di quale corrisponde a questo caso potrebbe essere in ordine, ma non conosco Mercurial abbastanza bene da rendergli giustizia. SCSS era prima del mio tempo!
git non è davvero così spaventoso come sembra. Bazzar d'altra parte .. beh comunque.
Lo svantaggio di SVN che permetteva modifiche su una singola sottodirectory era quando qualcuno ramificava una parte di un albero del codice che non includeva ** tutte ** le dipendenze di quel codice, non siamo mai stati in grado di ricreare la sua versione build candidato.
#2
+4
VicAche
2014-04-16 17:43:13 UTC
view on stackexchange narkive permalink

In questo caso, consiglierei di utilizzare https://draftin.com/, vedi qui per una rapida occhiata alle funzionalità specifiche che potresti voler utilizzare.

Uno svantaggio di questo software che voglio sottolineare prima di dare una risposta dettagliata alla tua domanda è che è pensato per essere utilizzato online. È possibile utilizzare la bozza senza una connessione Internet (vedere qui) ma ha ancora bisogno di essere perfezionata: la sincronizzazione, che è una funzionalità essenziale nella bozza, deve ancora essere attivata manualmente prima di andare offline.

  1. Controllo della versione: YES , decisamente. È una caratteristica fondamentale nella bozza ed è fantastico in quanto non intralcia quando non vuoi vederlo, ma è lì per servirti ogni volta che tu - o chiunque condividi i tuoi scritti - pasticcio con il documento. (Per impostazione predefinita, le modifiche di altri non sono incluse nelle tue versioni del documento, devi prima accettarle.)

  2. Compatibile con Ubuntu / Mint: YES , dopotutto è un sito web. Qualsiasi browser decente farà il trucco, ho testato la funzione offline solo su chromium, che ha un PPA per Ubuntu.

  3. Facile tagging / commenting / labeling: NO . Il punto è che la bozza dovrebbe gestirlo per te, consentendoti di contrassegnare le versioni principali e secondarie dei tuoi documenti e chiarendo chi ha apportato le modifiche. A questo proposito, la bozza non sarebbe lo strumento migliore per te.

  4. Semplice navigazione tag / etichetta, ricerca: non sono sicuro . Bene, se la bozza dei tag si adatta alle tue esigenze, almeno.

  5. Semplice "ripristino" delle versioni precedenti: . Non solo puoi recuperare le versioni precedenti, ma puoi anche conservare i bit utili in entrambe le versioni e modificare la versione corrente mentre visualizzi il diff con qualsiasi altra versione.

  6. possibilità di fare differenze: YES . La cosa a volte si sbaglia (il caso più fastidioso sarebbe quando si riscrive un paragrafo: draftin crede che io sostituisca ogni frase con una nuova, mescolando il vecchio e il nuovo nel diff, quando preferirei che il nuovo paragrafo fosse separato dal vecchio, ma i codici colore lo rendono meno orribile da gestire.) Le differenze funzionano bene, però.

  7. possibilità di sincronizzazione su macchine diverse: , a causa della natura della pagina web dell'oggetto. La modalità offline è strana, tuttavia, e richiede la sincronizzazione manuale.

  8. semplice struttura / gerarchia delle directory per i documenti: SÌ, ma , un po 'troppo semplice anche. Puoi mettere i documenti nella cartella, ma devo ancora trovare un modo per nidificare le cartelle, il che è un grosso svantaggio.

Per riassumere, la bozza si impone agli utenti , che è bello se ti piace (lo adoro). Sicuramente merita una prova nel tuo caso, ma la sua flessibilità molto bassa (tuttavia fornisce un'API, se sei interessato alla programmazione) potrebbe limitarne l'ambito.

Risposta utile (e probabilmente hai abbastanza rappresentante per modificare la tua risposta con i link, se lo desideri). Ho apprezzato in particolare la tua segnalazione di "difetti" (ad esempio, # 8), sebbene non siano "fatali". Uno pensa che * non * riesco a trovare: c'è un costo? Sembra essere implicito da Privacy e ToS, ma non riesce a trovare altre informazioni.
Lo uso gratuitamente, senza limiti di sorta. All'apertura della pagina web, viene visualizzato (ogni volta) un piccolo messaggio per farmi ricordare che potrei supportare lo sviluppatore e fornire i due modi in cui puoi pagare; 1. Un abbonamento mensile / annuale. 2. Un acquisto una tantum di un regalo per te o un amico. I regali sono recensioni di scrittori, intesi ad aiutarti in una specifica tranquillità di scrittura.
#3
  0
mmv-ru
2017-08-01 18:41:36 UTC
view on stackexchange narkive permalink

git è una buona soluzione per il controllo della versione. Speciale per il testo in chiaro.

  • Esamina il supporto del sistema di controllo della versione integrato in ReText. (Non riesco a trovare)
  • Prova i front-end git. Mi piace git-cola.
  • Prova strumenti esterni per diff / merge. Mi piace Meld.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...