Strumenti collaborativi per manichini / professori

Supponiamo che i coautori di due o più istituzioni diverse stiano scrivendo un documento in lattice e che vorrebbero fare di meglio che inviare ripetutamente e-mail bozze avanti e indietro.

Si rendono conto di poter aprire gratuitamente un account Dropbox, condividere la password e sincronizzare la versione del documento sul proprio computer con quella su Dropbox. Se due persone modificano contemporaneamente la stessa sezione, tuttavia, si sovrascriveranno reciprocamente le modifiche.

Hanno anche sentito che i sistemi di controllo della versione come SVN e Git dispongono di strumenti per unire i cambiamenti simultanei, che funzionano abbastanza bene. La documentazione di questi prodotti, tuttavia, è piuttosto difficile da leggere ed è più focalizzata su come annullare i cambiamenti e su come gestire diversi "rami" piuttosto che sulle esigenze di base dei coautori che scrivono un documento.

Esiste una semplice esposizione dettagliata su come utilizzare un sistema di controllo versione in questa configurazione:

• repository centrale
• copie locali
• unione "intelligente"
• senza rami

?

Dei sistemi di controllo versione standard, qual è il più facile da usare? (Stiamo parlando di professori di informatica teorica qui.)

Esistono strumenti ancora più semplici che si sincronizzano solo con l'unione intelligente, senza controllo della versione?

Al contrario, le persone che usano i sistemi di controllo della versione per scrivere anche un articolo a autore singolo ritengono davvero che la capacità di annullamento illimitato valga la complessità aggiuntiva?

Prima di tutto: se sei interessato all'editing collaborativo in tempo reale, prova qualcosa come gobby . Ti consente di modificare letteralmente un documento allo stesso tempo.

Per quanto riguarda i sistemi di revisione, conosco solo SVN. Questo è quello che fai, dopo aver installato sovversione, ovviamente:

1. Chiedi a qualcuno di creare un repository e fornirti URL, nome utente e password
2. Vai dove vuoi avere la tua copia lokal
3. In una shell (riga di comando?), Digitare: svn co url://to.your/repository (check-out). Ora appare una nuova cartella con il contenuto del repository.

È tutto. Ora i comandi più basilari:

• Ogni volta che aggiungi un nuovo filefoo , inserisci:svn add foo
• Ogni volta che vuoi rimuovere un file, inserisci: svn rm foo
• Ogni volta che hai apportato modifiche, inserisci: svn ci (check-in)
• Ogni volta che vuoi ottenere le novità, inserisci: svn up (aggiorna)

Ci sono anche comandi per spostare, copiare, ramificare, risolvere conflitti, ... ma finché non provi cose divertenti, stai bene con quanto sopra. Se qualcosa si rompe o sembra, fai il backup delle tue modifiche, elimina l'intera cartella e controlla di nuovo tutto. Questo è per svn come il riavvio di Windows.

Addendum: vedo che sembri preoccupato per le "fusioni intelligenti". Suppongo che ti riferisci a dover unire diverse versioni di un file, con il presupposto che due persone abbiano aggiunto cose in parti disgiunte del documento. Per quanto ne so, svn lo tratterebbe come un conflitto, e probabilmente giustamente. Non credo che esista una procedura generale che ti garantisca ciò che desideri dopo che due persone hanno manipolato la stessa fonte. Ci sono client svn grafici che visualizzano tali conflitti e ti aiutano a risolverli; sono praticamente dei visualizzatori diff dove puoi scegliere quale versione conservare per ogni riga in conflitto). Richiederà lavoro, comunque.

Noto che nessuno sta dando il "piccolo" tutorial per GIT , quindi proverò a coprirlo. GIT è più veloce e superiore a SVN, ma forse è più facile per te ottenere un account SVN su un server della tua università, poiché SVN è ben consolidato. Anche i tuoi collaboratori potrebbero sapere come usarlo.

Anche se collabori usando SVN, potresti voler usare GIT per il tuo versioning locale (lo faccio!).

Primo avvertimento : GIT è molto potente e per l'utilizzo di base è solo leggermente più difficile da usare rispetto a SVN (ad esempio, un'opzione da aggiungere nella riga di comando; due passaggi impegnano per il repository centrale).

Secondo avvertimento : GIT ha la filosofia di considerare atomica una serie di modifiche (a$\Delta$come lo chiamano) anche se il set comprende più file. Anche in GIT hai la nozione di repository locale e repository centrale . BUONO : puoi lavorare offline. MALE : sono necessari due passaggi per il commit su un server centrale .

Comandi di base supponendo che tu abbia già un repository

• Clona un repository: git clone <url>
• Aggiorna il tuo repository locale: git pull <repo>o solo git pullse hai clonato come sopra.
• Il comando pull fa davvero entrambi git fetche git merge. Il primo "recupera" roba dal server centrale e il secondo applica un'unione dei tuoi file con quelli del server.

L'unione è automatica finché non ci sono modifiche simultanee sulle stesse parti di alcuni file. Se l'unione fallisce, la directory di lavoro rimane in uno "stato di unione", il che significa che è necessario correggere i conflitti e quindi eseguire il commit della copia unita. Se hai ancora conflitti non gestiti nei tuoi file, il commit fallirebbe di nuovo, senza garbage commit.

• Aggiungere un nuovo file di essere impegnati: git add <file name>.
• Apporta modifiche al tuo repository locale : git commit -am "<textmessages>"ogit commit -a se desideri modificare i messaggi di commit.
• Inserire le modifiche nel repository locale nel repository centrale .

Nota che per inviare le modifiche al tuo repository centrale devi prima impegnarti nel tuo repository locale e devi spingere tutti i commit (anche più di uno) nel tuo repository centrale .

Creare un repository locale dell'utente

• Creazione di un repository git initin qualsiasi cartella che ti piace.
• Fatto!

Crea un repository condiviso (anche privato se paghi in contanti) con una bella interfaccia grafica.

• Usa GitHub

Crea tanti repository privati ​​/ pubblici con diversi gruppi di utenti ma senza interfaccia grafica.

• Richiedi un account SSH senza password su una macchina accessibile.
• Non preoccuparti poiché l'autenticazione viene eseguita dalle chiavi SSH.
• Installa Gitosis secondo questo tutorial .
• Ora puoi amministrare il tuo server git modificando un singolo file e trasferendolo nel repository!

Git non ha bisogno di un server centrale : qualsiasi cartella nel tuo computer può essere utilizzata come repository, quindi puoi giocare con git e rendere offline i tuoi test. È possibile inizializzare un repository e simulare tre collaboratori in altre tre cartelle senza inviare un bit in rete. Questo perché qualsiasi copia clonata del repository è un repository completo in cui è possibile eseguire il commit. Questo è utile se vuoi lavorare in un volo tra Stati Uniti, Cina o Europa.

Google Documents ( https://docs.google.com ) fornisce ottimi strumenti per creare documenti insieme (inclusa la modifica in tempo reale). Memorizza tutto online per te e si integra bene con il tuo account Gmail. Per impostazione predefinita, Google Documenti non ha compatibilità LaTeX, ma puoi abilitarlo andando qui:

http://docs.latexlab.org/

Non sono sicuro di come funzioni per il rollback, ma sono sicuro che ci sia una funzione per farlo. Ho sentito parlare di alcune persone che utilizzano il plug-in LaTeX di Google Wave per elaborare bozze preliminari di documenti.

Faccio in modo che i miei coautori imparino Mercurial, e li facevo imparare Subversion. Se sei un fan di Subversion, leggi questo , è tutto vero.

Indipendentemente dal sistema in uso, la cosa di gran lunga più difficile è convincere l'altra persona a installare il software e iniziare a usarlo. Skype è la soluzione perfetta. Le versioni recenti di Skype consentono la "condivisione desktop" che aiuta davvero quando vuoi guidare il tuo coautore attraverso la procedura di installazione. E ho usato la condivisione desktop diretta in combinazione con Skype per scrivere un documento con il mio coautore. Funziona abbastanza bene.

Ciò che è veramente necessario è un "Github per scienziati". Qualcosa che fornisce un repository, ha il controllo della versione, l'editing collaborativo, ecc. Indovina, c'è http://www.scribtex.com/ .

ecco un nuovo editor collaborativo di Latex online chiamato WriteLatex che sembra promettente, come uno sportello unico per molte esigenze / requisiti di scrittura scientifica.

• funziona su cellulare
• ha un'anteprima in tempo reale
• condivisione facile / privata
• trova errori in lattice
• consente di aggiungere librerie / stili in lattice
• cloud storage

il coautore John Hammersley ha pubblicato un annuncio in tcs se meta qui ed è sensibile al feedback (altri 5 voti sull'annuncio e apparirà sul sito principale). sembra che potrebbe evolversi nel tempo in uno strumento prezioso per la comunità di tcs e forse gli autori saranno in grado di implementare alcune funzionalità popolari specificamente su richiesta.

Che dire di sistemi semplici, soluzioni:

• Google Docs, Zoho writer ... e altri strumenti di collaborazione.
• Dropbox gestisce le situazioni in cui due persone tentano di eseguire il commit delle modifiche sullo stesso file. La seconda persona che esegue il commit ottiene il suo file rinominato (X.txt -> X.txt_blabla ...) e il file originale (X.txt) aggiornato con la versione più recente. Maggiori informazioni su: Aiuto Dropbox: "Cosa succede se due persone cambiano lo stesso file?"

È fuori discussione, ma a volte ci sono situazioni in cui parte del gruppo è in grado di soluzioni semplici come SVN, mentre l'altra parte del gruppo è in grado di controllare la versione distribuita come GIT. In tali situazioni è possibile la cooperazione:

• git-svn - Operazione bidirezionale tra un repository Subversion e git
• Git - SVN Crash Course
• Usare efficacemente Git con Subversion

Di recente ho scoperto sharelatex.com e l' ho usato con il mio collaboratore per creare un articolo. Mi è piaciuto così tanto che il mio piano attuale è di usarlo per tutti i miei progetti. Alcune caratteristiche degne di nota:

• TeXing in tempo reale nel browser (come Google Docs, ma realizzato per TeX, evidenziazione della sintassi e tutto il resto).

• Compilazione nel browser e visualizzazione di PDF

• Supporta progetti con più file

• Ha una funzione di cronologia

• Si sincronizza con Dropbox (che sarà presto rilasciato pubblicamente, dal suo attuale stato beta). In questo modo è possibile scaricare su Dropbox il salvataggio di backup ecc. A seconda di come è fatto, questo dovrebbe anche permetterti di usare sharelatex anche se i tuoi coautori non lo vogliono, purché siano disposti a usare Dropbox per condividere file.

• Puoi scaricare / caricare il tuo progetto in qualsiasi momento, quindi non sei bloccato usando sharelatex se qualcosa va storto o cambi idea o altro.

L'unico aspetto negativo (ma penso che ne valga la pena): sebbene l'uso di sharelatex sia gratuito, alcune delle sue caratteristiche non lo sono. In particolare, per utilizzare la sincronizzazione di Dropbox (quando lo rilasciano) o se vuoi che più di 6 coautori lavorino allo stesso progetto sharelatex, devi pagare $ 8 / mese. o $ 80 / anno [da aprile 2013]. Una volta rilasciata la sincronizzazione di Dropbox, mi sembra un prezzo molto giusto.

[Dichiarazione di non responsabilità: non ho alcun rapporto con Sharelatex o i suoi dipendenti se non quello di utilizzare il loro prodotto.]

SVN è lo strumento sviluppato per questo scopo. Mi impegnerei per impararlo. Non è più complicato di come imparare ad usare il pacchetto Latex algoritmico o uno dei pacchetti Latex del creatore di diapositive pdf.

Detto questo, uso CVS invece di SVN. C'è un migliore supporto da parte degli amministratori CS presso la nostra istituzione (il server SVN è più gestito dall'utente). Inoltre, apprezzo che i file di versione sottostanti siano ancora lì e modificabili se qualcosa va molto male.

Ci sono 2 svantaggi rispetto a SVN. I nomi dei file non sono così belli, ma posso conviverci (scegli un buon nome la prima volta). Il secondo problema è che è necessario un account CS locale per accedere al repository. Pertanto, da un altro istituto l'accesso è possibile solo se viene creato prima un account. Ovviamente non mi aspetto che questo sia un vero problema da nessuna parte; un membro del dipartimento locale può probabilmente sponsorizzare tale account.

La restrizione di accesso locale è dovuta al fatto che gli amministratori non vogliono supportare un pserver. (Più difficile da proteggere, ecc.)