Controllo della versione per la collaborazione (con differenze a livello di parola)?

20

La maggior parte degli articoli sono ora scritti in modo collaborativo e i collaboratori si trovano spesso in luoghi diversi. Ho sempre usato i sistemi di controllo della versione per i miei documenti e codice, e ho anche trovato il controllo della versione fondamentale per progetti software collaborativi, ma sembra che molti ricercatori in teoria evitino il loro uso per scrivere documenti comuni. Per convincere i miei collaboratori che il controllo di versione (controllo di revisione) è una buona idea per lavorare insieme, sembrano esserci dei prerequisiti. Non è possibile forzare tutti a preoccuparsi di un insieme specifico di convenzioni per le interruzioni di riga e i paragrafi o per evitare conversioni di tabulazione / spazio.

Qualcuno offre l'hosting gratuito di piccoli repository di documenti condivisi, con controllo di versione testuale per documenti in grado di gestire differenze a livello di parola ( non basate su riga)?

In caso contrario, accolgo con favore altri suggerimenti basati sull'esperienza (evitiamo la speculazione, per favore).

Stavo pensando a Git, Subversion, Mercurial, darcs o Bazaar, impostati per gestire le differenze a livello di parole con wdiff, insieme a un modo semplice di impostare l'accesso garantito da chiavi pubbliche (ad esempio via ssh). Tuttavia, nessuno dei provider di controllo versione che ho esaminato sembra offrire qualcosa del genere. Per la collaborazione scientifica, le caratteristiche "aziendali" sottolineate da molte di queste aziende non sono molto importanti (molte filiali, integrazione con trac, audit da parte di terzi, team di progetto gerarchici). Ma le differenze a livello di parole sembrano critiche ma non supportate. Nella mia esperienza, con le differenze a livello di riga per i file di testo, tutti devono evitare di riformattare paragrafi ed editor che cambiano le schede in spazi o viceversa causino problemi; sembrano esserci anche molti conflitti di modifica spuri.

Vedi le domande correlate su MO sugli strumenti per la collaborazione e domande correlate su TeX.SE, sul controllo delle versioni per i documenti LaTeX e sui pacchetti LaTeX per il controllo delle versioni . Vedi anche la tabella di revisione del confronto di hosting SVN per un ampio elenco di provider di hosting, solo per uno dei principali sistemi di controllo della versione.

Modifica: la risposta di Jukka Suomela alla domanda di TeX.SE "I migliori strumenti diff e di unione per la sovversione compatibili con LaTeX " sembra essere finora il miglior suggerimento, coprendo come interpretare i delta a livello di parola. Inoltre, Jukka ha spiegato come le differenze tra le versioni successive sull'estremità del repository siano separate dalle differenze a livello di utente utilizzate per il rilevamento dei conflitti e l'unione delle modifiche. La risposta di Jukka su TeX.SE esclude esplicitamente le modifiche e le fusioni simultanee, basandosi invece sul tradizionale token di modifica atomica per evitare conflitti di modifica. Chiarendo (e modificando) la mia domanda originale, c'è un modo per garantire che i conflitti di modifica possano essere risolti sulla base di una differenza di parola, piuttosto che su una differenza di linea? In altre parole, canwdiffo strumenti simili possono essere integrati nella parte di rilevamento dei conflitti degli strumenti di controllo della versione, in modo simile al modo in cui le differenze di fine linea e le differenze negli spazi bianchi possono essere ignorate?

— András Salamon
fonte

3

Non capisco bene la domanda. Ad esempio, in SVN, le differenze visualizzate a un utente sono generate dal client e dipende dal client SVN (e dalla sua configurazione) se si ottengono differenze basate su parole o differenze basate su linee. La società che ospita il repository SVN non influisce affatto su questo.

— Jukka Suomela,

2

@suresh Se stai modificando documenti (scritti) di testo, spesso è difficile scansionare un'intera riga in un diff per vedere che qualcuno ha cambiato una virgola. Il comportamento corretto di solito è mostrare l'unità minima di cambiamento. In alternativa, considerare il comportamento se qualcuno non utilizza le interruzioni di riga. Quindi la modifica di una sola parola farà apparire l'intero paragrafo nel diff per voi per trovare il piccolo cambiamento.

— Mark Reitblatt,

2

Non uso interruzioni di riga per avvolgere le righe. Nel mio codice sorgente di Latex, una riga di testo fisica è di solito un intero paragrafo di testo. L'editor può racchiuderlo in parole per la visualizzazione, a seconda della larghezza della finestra corrente. Semplifica molto le cose; non c'è mai bisogno di preoccuparsi di cose come dovrei ri-racchiudere in una parola un paragrafo, o concordare la larghezza della linea "giusta" con i tuoi co-autori. Tuttavia, avrai bisogno di uno strumento diff a livello di parola per vedere rapidamente le modifiche.

— Jukka Suomela,

2

@Andras Il mio punto era che il sistema VC deve solo essere in grado di ricostruire le due revisioni sul lato client, e non sorprendentemente tutti i sistemi VC possono farlo. Ciò di cui hai quindi bisogno è un'utilità di fusione a tre vie a livello di parola, ma non ne conosco nessuna. (Ad esempio, TortoiseMerge e kdiff3 sono entrambi basati su linea.) Una volta che hai una tale utility, sarà sufficiente qualsiasi sistema VC che ti permetta di specificare un'utility di fusione esterna. (Ciò include svn, bzr, git, hg ...)

— Maverick Woo,

3

Una fonte di confusione qui è che esiste un algoritmo binario diff diff (che opera a livello di singoli byte) che viene utilizzato da SVN nella comunicazione tra il server e il client, e anche internamente dal server per mantenere il repository compatto. Questa è semplicemente un'ottimizzazione; non è visibile all'utente e lo stesso algoritmo diff binario può essere applicato a qualsiasi tipo di file. Tutte le cose visibili all'utente (differenze leggibili dall'uomo, fusione, risoluzione dei conflitti ...) accadono sul lato client.

— Jukka Suomela,

11

Ho usato git per collaborare ad alcuni documenti scritti in lattice. Dovrai rispettare alcune regole:

Inizia ogni frase su una nuova riga, il lattice ignora queste nuove righe purché non ci sia una riga vuota
Usa la stessa configurazione per la formattazione (tab / spazi / larghezza massima del testo)
Per risultati ottimali, creare un file .gitattributes nel repository e aggiungere la riga *.tex diff=tex. Questo rende diff consapevole della sintassi tex e porta a un output più significativo.

È quindi possibile utilizzare git diff --color-words e gitk --color-wordsvedere le differenze di parole (vedi anche questo articolo Differenze parola per parola in Git su come configurare git per usare sempre l'algoritmo word-diff per visualizzare il registro git diff / git).

Per ridurre le unioni manuali, posso consigliare di utilizzare file separati per sezioni e sottosezioni (a seconda delle dimensioni del documento).

— Davy Landman
fonte

Prenderò in considerazione di farlo per i miei documenti, sembra essere un modo semplice per raggiungere la maggior parte dei miei obiettivi. Ma non tutti sono entusiasti di lavorare in questo modo ...

— András Salamon,

2

Per le persone che esitano a lavorare in questo modo, puoi usare TortoiseGit se non gli piace la riga di comando git. Se si tratta di ogni frase su una nuova parte di riga, purché non sia forzata la larghezza massima del testo, questo non è così importante. (Ho lavorato su alcuni progetti senza quella regola)

— Davy Landman,

Nel complesso, sono d'accordo che Git sia una buona scelta. Ma perché i file separati per (sotto) sezioni possono ridurre il numero di fusioni manuali? Mi chiedo anche come sia utile iniziare ogni frase su una nuova riga (a volte le frasi si mescolano nel processo di modifica).

— gg1

per quanto riguarda i file di separazione: a quel tempo, non capivo i dettagli esatti della fusione di git, quindi in realtà non è necessario, ma è comunque consigliabile per altri motivi. La frase su una nuova riga è molto importante, poiché la maggior parte degli strumenti intorno a git mostra sempre i cambi di linea, se poi usi un'altra strategia, diciamo che lascia che l'editor faccia delle interruzioni di riga, ogni volta che qualcuno cambia 1 parola in un paragrafo, dovrai cacciare dove succede, e in caso di fusione automatica: niente da fare.

— Davy Landman,

4

Suggerisco di dare un'occhiata a:

LaTeX / Scrittura collaborativa di documenti LaTeX ,

e il relativo documento:

Strumenti per la scrittura collaborativa di documenti scientifici LaTeX .

— MS Dousti
fonte

2

Sfortunatamente le "migliori pratiche" in questi documenti sono precisamente i tipi di cose che non si possono forzare sui collaboratori.

— András Salamon,

4

Voglio davvero fare eco agli altri e suggerirti di sederti e elaborare una bella strategia SVN. Uso SVN per ospitare la mia intera struttura di "ricerca":

Gestione dei riferimenti JabRef
PDF scaricati
articoli

È fantastico perché contiene tutto e ovviamente fornisce una storia. L'avvertenza è che hai bisogno del tuo server. Ma se hai qualche macchina Windows esistente (o qualunque cosa tu abbia familiarità ) puoi installarla semplicemente tramite VisualSVN Server . Quindi crei account appropriati per i collaboratori e dai loro l'accesso a un'area appropriata (ad esempio, forse l'accesso in lettura al tuo file bibtex JabRef e leggi / scrivi in un'area articolo condivisa in corso).

TortiseSVN può essere utilizzato come client Windows per interagire con SVN. Devi fare attenzione a spostare / eliminare file e copiare cartelle (SVN memorizzerà i metadati all'interno di cartelle nascoste in ciascuna delle tue cartelle, quindi devi eseguire il comando di eliminazione da SVN per sbarazzartene, ci vuole un po 'di tempo per abituarsi a, ma vale l'investimento).

Quindi, quando lavorano con un collaboratore, devono chiaramente usare anche SVN. Ma, di nuovo, l'investimento nell'apprendimento non è inutile. E tramite alcuni pensieri, puoi anche averlo in modo da avere accesso in sola lettura al loro file jabref (forse tramite la funzione 'esterna' in svn).

In questo modo, con un po 'di pensiero e un po' di sforzo, puoi trovarti in una situazione in cui stai modificando i documenti come di consueto, eseguendo le modifiche di notte, aggiornando al mattino e risolvendo facilmente tutti i conflitti.

Lo consiglio davvero. Maggiore è il numero di persone che creano i propri SVN, meglio sarà, poiché migliorerà solo le opzioni di collaborazione in futuro (anche se, naturalmente, sarebbe utile se forse ci fosse un modo "standard" di creare un repository scientifico).

- Modifica: infatti, ho scritto una proposta del genere qui: Strategia per la collaborazione scientifica con LaTeX e SVN . Propone di utilizzare la funzione svn externals per consentire una facile collaborazione tra persone con una configurazione simile. Fammi sapere se deve essere modificato o semplicemente non è appropriato.

— Mezzogiorno Seta
fonte

4

Mentre leggevo il tuo ottimo post e mi cercavo una soluzione, mi sono imbattuto nell'opzione per colorare i cambiamenti a livello di parola in gitk . Il parametro gitk sembra essere una funzionalità nuova e / o non documentata poiché il completamento automatico non lo offre e la pagina man di gitk non lo elenca.
Ecco le opzioni che ho trovato:

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

Puoi trovare diverse discussioni su quell'argomento alla ricerca di gitk "diff --color-words" .

Modifica:
ecco come appare ...

Differenze colorate a livello di parola usando gitk

— JJD
fonte

1

Capisco molto bene il problema. Ho iniziato a usare Kaleidoscope per diff con Git. È solo per Mac ma i suoi confronti funzionano meglio di wdiff, e ha anche un'interfaccia e aggiornamenti live.

2

Per me sembra che Kaleidoscope sia solo uno strumento diff basato sulla linea che, inoltre, evidenzia i cambiamenti all'interno di ogni linea. Non è un sostituto di wdiff e amici. Caleidoscopio produce differenze illeggibili se, ad esempio, prendi solo un paragrafo di testo e modifichi alcune interruzioni di riga. Gli strumenti basati su Wdiff ignorano semplicemente le modifiche nelle interruzioni di riga.

— Jukka Suomela,