tl; dr: Il controllo della versione è più difficile da configurare, ma rende sicuro lavorare sullo stesso file e semplifica il monitoraggio della cronologia (ad esempio le versioni precedenti).

Pro e contro della sincronizzazione dei file

Sì, il più grande vantaggio di cose come Dropbox (lo uso anche per il backup e la sincronizzazione dei miei file) e SugarSync è la loro facilità.

Possono funzionare per la collaborazione sui file, ma:

• non sono pensati per due persone che modificano lo stesso file contemporaneamente (nessuna funzionalità di unione, quindi un ragazzo che cambia un il file può sovrascrivere le modifiche apportate da altri, anche senza saperlo),
• non si ottiene alcuna cronologia, ad esempio:
  • qualcuno ha lavorato su quel file che voglio lavorare lo sa? >
  • Qualcuno ha aggiunto o modificato altri file?
  • quali modifiche sono state apportate?
  • posso passare a una versione precedente, quella che ho inviato al mio supervisore?

A seconda di quello che fai, potrebbe non essere un problema. Ad esempio, se solo uno sta modificando il file tex , mentre altri stanno solo leggendo o caricando cifre, va benissimo.

Inoltre, guarda la mia risposta su Il più semplice modo di scrivere insieme un manoscritto? con collaboratori non tecnicamente inclini.

Controllo della versione

I sistemi di controllo della versione richiedono alcune competenze tecniche.

Due dei sistemi di controllo delle versioni più comuni sono Git e Mercurial (il secondo è più compatibile con Windows e, probabilmente, più facile da avviare).

Entrambi di serie vengono forniti solo con l'accesso alla riga di comando, ma ci sono anche alcune interfacce grafiche (consiglio vivamente di iniziare con SourceTree).

Quindi, se i collaboratori sono tecnici, insegna loro come usarlo. In caso contrario, c'è un modo per aggirare.

Puoi tenere traccia del controllo della versione da solo, senza coinvolgere gli altri (lo sto facendo solo ora con 2 collaboratori).

Basta avvii un repository all'interno della cartella che condividi (gli esempi sono con Git):

  cd ~ / path / to / the / folder
git init // avvia il repository git all'interno di questa cartella // dì git per tenere traccia di tutti i file al suo interno  

Ora, ogni volta che tu o il tuo collaboratore apportate alcune modifiche (ad es. aggiungi alcuni file, correggi errori di battitura, rivedi un capitolo, ...) do:

  git commit -a -m "Corretti errori di battitura in Seciton 3"  

Successivamente, sarai in grado di tornare a questa versione; e anche confrontare, ad es. la versione corrente del tuo file con quella precedente (per impostazione predefinita - per riga, qui - per parole):

  git diff HEAD ~ 1 --color-words my_file.tex  

Vedi anche:

• Hai 15 minuti e vuoi imparare a usare Git?
• Flusso di lavoro git + LaTeX a StackOverflow
• Scrivere la tesi di dottorato: gli strumenti Parte I
• Collaborare con LaTeX e git sul blog di ShareLaTeX - un ottimo e completo tutorial
• Quali sono i vantaggi dell'utilizzo del controllo della versione (git, CVS ecc.) nei documenti LaTeX - TeX.SE
• https://tex.stackexchange.com/search?q=version+control

E un esempio del mondo reale dall'uso di diff (mi rende la vita molto più semplice: )); commettere messaggi in polacco, ma immagino che tu abbia l'idea:

Altrimenti ( una striscia da PhD Comics):

Non sono del tutto sicuro di come funzionano Dropbox e Sugar Sync, ma il loro scopo principale non è monitorare le modifiche, ma mantenere i file sincronizzati su una moltitudine di piattaforme e fornire backup. Inoltre, un buon sistema di controllo delle versioni ti consente di mantenere le versioni precedenti , ma anche di commentare le modifiche per spiegare perché sono state apportate. Il controllo della versione è anche garantito per mantenere la catena di modifiche di un file tex anche per periodi di tempo molto lunghi (ad esempio, sottomettersi alla rivista a, essere rifiutati, inviare alla rivista b, ottenere recensioni, nuova versione, accettazione: un tale ciclo facilmente essere di 1,5 anni).

Inoltre, in un sistema di controllo della versione (VCS) hai deciso quando vuoi salvare una versione , nella casella personale posso immaginare che il sistema prenda quella decisione. Avere il controllo di se stessi è importante, ad esempio per essere in grado di generare un file di differenza quando si invia nuovamente un articolo (vedere anche la mia risposta a questa domanda su TeX SE).

Utilizzando VCS puoi anche collaborare facilmente con le persone . Basta creare un repository privato su bitbucket (supporta mercurial e git), fare in modo che gli altri autori abbiano accesso in lettura e / o scrittura ai tuoi file tex nel repository, e possono cambiare il foglio o aggiungervi. Il VCS si prenderà cura della fusione.

Io stesso uso Mercurial per i documenti di controllo della versione. Tuttavia, per il controllo della versione di un file tex, un VCS potrebbe essere eccessivo. Tuttavia, consiglierei comunque Mercurial.

Visti gli elogi ricevuti dai sistemi di controllo della versione nelle risposte esistenti, farò qui per un secondo l'avvocato del diavolo e sottolineerò quello che penso sia un punto molto importante: dipende fortemente da ciò che i tuoi coautori sono a proprio agio con .

Uso il controllo della versione per la maggior parte dei progetti che faccio da solo, dal codice ai documenti. Tuttavia, devi capire che non tutti hanno familiarità con questo paradigma, e coloro che lo conoscono potrebbero non avere familiarità con un dato software (io stesso sono un utente pesante di Subversion, ma non ho mai usato Git…). Ciò è particolarmente vero per le persone che non sviluppano software, poiché questi strumenti provengono dal campo dello sviluppo del software. Quindi, controlla cosa usano i tuoi coautori e cosa sono disposti a imparare. La cosa grandiosa di una semplice soluzione di sincronizzazione (come DropBox) senza controllo della versione è che la sua curva di apprendimento è piatta : basta concordare alcune regole (data su tutti i file, aggiungi le iniziali, invia sempre un'e-mail quando hai creato una nuova versione). Chiunque può capirlo in un minuto.

Infine, aggiungerò un'altra osservazione: la necessità di tenere traccia della cronologia delle revisioni a breve termine non deve necessariamente richiedere la registrazione della cronologia delle revisioni per i posteri. Ad esempio, il mio sistema di backup incrementale (Time Machine di Apple) crea istantanee della cronologia dei miei file ogni ora per un giorno, ogni giorno per il mese passato e così via. Ciò copre alcune delle necessità di tenere traccia delle versioni precedenti a breve termine.

quanto sono utili (specialmente con le impostazioni Latex) per scrivere documenti rispetto a dropbox e SugarSync?

Sono un utente di lunga data dei sistemi di controllo delle versioni, in effetti tutto Ho (la mia cartella $ HOME) viene eseguito il backup in un VC.

Ho provato a usare vari sistemi di controllo delle versioni per scrivere molti (10+) articoli di ricerca, tutti scritti in LaTeX. La mia esperienza con l'utilizzo di VC per scrivere articoli di ricerca è tuttavia mista, se non addirittura negativa. Oltre alla facilità di sincronizzazione con un VC, il problema principale è l'unione degli aggiornamenti. A differenza del codice sorgente dei programmi, l'unione di LaTeX non è così semplice principalmente a causa di problemi di interruzione di riga. In secondo luogo, anche se non ho problemi con i vari VC, i miei coautori (un mix di persone molto eterogeneo) non hanno necessariamente esperienza con quello che uso, o ne usano uno diverso a titolo definitivo, o non hanno idea di queste cose. Aggiungi la bizzarria dell'impostazione di password, tunnel ssh, installazione di software lato client ecc. E vedrai che, tutto sommato, utilizzare un VC non è un'esperienza fluida (nella migliore delle ipotesi).

Recentemente (3 documenti finora), ho provato Dropbox e sono abbastanza soddisfatto del risultato. Anche se non risolve tutti i problemi, mi sembra che risolva almeno alcuni:

• set-up quasi zero, anche i profani non hanno problemi a installare il client
• nessuna sincronizzazione esplicita, tutto funziona all'istante (niente svn / git / bzr / ... aggiungi / rimuovi / sposta / ... elementi della riga di comando coinvolti)
• i problemi di unione sono più o meno gli stessi di una versione sistema di controllo - anche con un vc in posizione, tendevo sempre a inviare notifiche di blocco in scrittura esplicite ai coautori via e-mail, o IM
• dropbox ha un controllo delle versioni rudimentale, per i miei scopi è abbastanza sufficiente. Scrivere articoli non è questione di ramificazioni, giusto?
• inoltre, non è necessaria alcuna configurazione del repository. Devi solo condividere una cartella con un gruppo selezionato di coautori e il gioco è fatto. Nessun altro può vederlo. Pochi clic, quasi zero problemi.

Come vedi, il mio consiglio è di rimanere con una soluzione simile a Dropbox . Almeno per i miei scopi, si è rivelata la soluzione migliore finora.

Consiglio vivamente di utilizzare il controllo della versione per scrivere un articolo perché i miei consiglieri non sono mai stati molto bravi nell'uso dei computer. Spesso modificano le versioni sbagliate dei documenti e poi me le inviano. Quindi devo capire cosa hanno cambiato e reinserirlo manualmente nella mia ultima versione. Aggiro questo problema tenendo traccia di quale versione ho inviato loro tramite email e quindi confrontando ciò che mi hanno inviato utilizzando i tag di rilascio.

Non dare per scontato che il capo utilizzerà mai il controllo della tua versione sistema. Non ne ha bisogno. Ma è comunque estremamente utile usare il controllo della versione! I nostri documenti sono preparati in MS Word perché è tutto ciò che il capo sa usare, ed è il formato di file che vuole il giornale. Spesso si dimentica di utilizzare la funzione "Rileva modifiche", ma puoi utilizzare "Confronta e unisci documenti" nel menu Strumenti per determinare cosa ha modificato. (Basta "unirlo" con la versione che hai inviato via email, e il documento risultante mostrerà le differenze usando l'evidenziazione "Rileva modifiche".) Non devo mai confrontare i timestamp o preoccuparmi di quale file è l'ultima versione, e anche quando MS Word distrugge una delle mie figure So che posso recuperarla facilmente.

Puoi mantenere tutti i tuoi dati sperimentali grezzi, il codice di post-elaborazione, i file di figure e le note di laboratorio anche sotto il controllo della versione . Quindi puoi eseguire il backup dell'intero repository ed essere davvero sicuro di non perdere nulla. Applico tag a livello di repository per indicare quando eseguo nuovi esperimenti, il che aiuta a mantenere il codice sincronizzato con i dati; questo risponde alla vecchia domanda su quale metodo è stato utilizzato per generare le figure. ("Era il metodo A? L'abbiamo usato l'ultima volta sei mesi fa, ma avrebbe potuto essere un metodo B simile che abbiamo iniziato a sviluppare in quel periodo. Forse abbiamo usato A.1? Ottimo, dovremo farlo da capo di nuovo ... ")

Puoi utilizzare la funzione di push del repository come un tipo di sistema di backup distribuito. Uso TortoiseHg (una GUI Mercurial per Windows) per eseguire il push / pull del repository verso un'unità flash USB da portare tra il computer di casa e quello di lavoro e anche in una condivisione di rete come backup, e non sovrascrivo mai i file sbagliati o faccio copie extra dei file. A proposito, dimentica di usare le funzionalità di ramificazione e fusione: non hanno davvero senso per i file binari, ma è utile sapere se sono state modificate accidentalmente. Mercurial funziona abbastanza bene, anche con enormi file binari in formati proprietari del fornitore.

Riepilogo: Gli esperimenti scientifici del mondo reale producono troppi file per la versione manuale, e il capo potrebbe non essere molto esperto di tecnologia . Il controllo della versione risolve questi problemi e non dovrai mai più ordinare i nomi dei file con date casuali codificate in modo fisso.

Ci sono molti aspetti positivi nelle altre risposte, ma vorrei aggiungerne un altro, riguardante la gestione del tempo / progetto. Sebbene tu possa eseguire il controllo della versione con Dropbox, il principale punto di forza di Dropbox è che tutti lavorano sugli stessi file contemporaneamente, il che lo rende veloce e sempre sincronizzato, ed è abbastanza buono per una "corsa", dove n le persone devono lavorare insieme per un determinato periodo di tempo su un determinato obiettivo.

Tuttavia, attualmente sto lavorando su più di 5 articoli contemporaneamente, con vincoli di tempo diversi, scadenze diverse e coinvolgimento diverso, e apprezzo avere facilmente la storia del giornale, chi ha commesso cosa / quando, e mi piace dover impegnare contributi per un articolo. Quindi, so che la versione sul repository principale è coerente e posso lasciare alcune parti appese a un repository locale senza rompere tutto, e quando mi impegno, devo sforzarmi di capire cosa è effettivamente cambiato e qual è l'interesse . A questo proposito, può essere molto utile anche il fatto che tu possa facilmente associare un issue tracker a un repository (ad esempio con BitBucket) (ad esempio, puoi aggiungere un problema "cita questo altro documento" , allega il documento e risolvi il problema quando imposti il ​​paragrafo citando effettivamente il documento.

Questo approccio alla gestione del progetto potrebbe essere un pregiudizio proveniente dal mio background di programmazione e potrebbe essere eccessivo in alcuni casi, ma in Alla fine, non c'è nessuna caratteristica killer da un approccio o dall'altro, è anche quanto ti rende la vita comoda.

Non ho esperienza con quello che sto per suggerire, ma potrebbe essere utile. Utilizza entrambi ; utilizza sia Dropbox e alcuni VCS . Come? Bene, nella cartella Dropbox che desideri condividere, avvia un repository git (vedi risposta @PiotrMigdal). Per quanto ricordo puoi escludere una directory dalla sincronizzazione in Dropbox e dovresti escludere la directory .git (nascosta-) poiché non interessa i tuoi collaboratori.

In questo modo, tu e i tuoi collaboratori potete condividere facilmente i dati su Dropbox e personalmente potrete godere dei vantaggi di un vero e proprio VCS su vasta scala.

Tuttavia, come sempre con il lavoro digitale condiviso, una delle questioni più importanti è stabilire le linee guida: dovrebbero essere chiare a tutti i partecipanti.