Non utilizzare il controllo della versione è negativo.

A seconda di chi lavoro, le soluzioni basate su cloud [, con controllo della versione] per lavorare in modo collaborativo non sono sempre un'opzione.

Puoi utilizzare soluzioni basate su cloud anche quando alcuni collaboratori sono contrari. Tutto ciò che devi fare è: scaricare e inviare tramite email la versione cloud a collaboratori che rifiutano di utilizzare il cloud e caricano tutto ciò che restituiscono.

Vengo da un campo in cui nessuna di queste risposte funzionerà. Ricorda, la maggior parte degli scienziati non sono informatici. Come studente universitario, l'invio ai professori di regole arcane per le convenzioni di denominazione verrebbe probabilmente ignorato. Ognuno ha il proprio schema abituale e, anche se volesse essere d'aiuto, potrebbe semplicemente dimenticare quando arriva il momento di risparmiare. Ciò che mi infastidisce sono le persone che inseriscono spazi nei nomi dei file.

Per quanto abbia intenzione di migliorare questo processo se mai gestissi il mio laboratorio, ecco cosa devi fare:

Il primo autore (o l'autore che guida la pubblicazione, o l'autore corrispondente, o qualcuno scelto per facilitare) gestisce lo spettacolo.

1. Quando tu invia una bozza, indica una data entro la quale desideri ricevere i commenti (due settimane è una buona regola pratica). Non apportare le tue modifiche nel frattempo se puoi aiutarlo.
2. Quando invii una bozza, inserisci una data. Quando le persone iniziano a inviarti commenti, a volte le persone saranno gentili e ne modificheranno uno che qualcuno ha già modificato. IME, non sempre accade.
3. Alla fine del periodo di tempo o dopo aver ricevuto i commenti di tutti, utilizza lo strumento unione documenti di Word.
4. Salva con la nuova data e inizia a incorporare modifiche e a rispondere ai commenti.
5. Risciacqua e ripeti.

Ti ritroverai con molti file, con date diverse. Conservo i file solo dal passaggio 4, una volta che sei sicuro dell'unione. Francamente, lo spazio costa poco e personalmente trovo più facile aprire paper-200303.docx per trovare un vecchio commento rispetto agli strumenti di revisione (per Word). Quando il documento viene accettato, puoi eliminare le vecchie versioni.

La chiave per un controllo delle versioni moderno come git è conoscere i documenti principali di un documento. È quindi necessario essere in grado di ricostruire quale sia la versione immediatamente precedente.

Quindi, chiedi loro di contrassegnare la loro versione con il loro nuovo numero di versione e nome, almeno, ma, idealmente, aggiungi da quale versione l'hanno costruita (o più di questi se si trattava di una fusione)

Quindi, come minimo, OP potrebbe usare -.-. txt.

Quindi si potrebbe dedurre che rollingstones-4.2-PK.txt è stato derivato da PK da (probabilmente) 4.1. Così come rollingstones-4.2-IR.txt ha probabilmente anche 4.1 come genitore, ma modificato indipendentemente da qualcun altro. Quando unisci versioni con lo stesso numero, puoi omettere l'autore e assegnargli semplicemente il numero seguente, ad es. se rolling stones-4.3.txt è una fusione dei precedenti.

Se puoi permetterti e le persone sono disciplinate, sarebbe utile contrassegnare l'immediato predecessore, però: rollingstones-4.4-UM-from-4.3-PK.txt. Questo è un po 'goffo e una scarsa imitazione dei moderni VCS come git, ma ti consente di dedurre i genitori della versione attuale che è tutto ciò di cui hai bisogno in definitiva.

Per facilitare ciò, chiedi alle persone, direttamente al download dell'ultima versione, di duplicarla e modificarne immediatamente il nome per riflettere la genitorialità della versione scaricata.

Sono sorpreso che nessuno abbia menzionato il classico sistema "token" / "cookie".

Il modo in cui scrivevo articoli con i coautori 20 anni fa utilizzava un sistema informale di token. Se volevo modificare la sezione 1 del documento, anche solo per correggere un singolo errore di battitura, dovevo seguire questi passaggi:

• Invia un'email a tutti i coautori con il testo "Sto rivendicando il token per la sezione 1. "
• Modifica sezione 1
• Invia un'email a tutti i coautori con la loro versione modificata della Sezione 1 e il testo " Sto rilasciando il token per Sezione 1. "

Nessuno era autorizzato a mantenere il token per qualsiasi sezione oltre un limite concordato. tipicamente 24 ore, ma spesso si riduceva a 2 ore o addirittura a 15 minuti con l'avvicinarsi delle scadenze. In linea di principio, tutti potevano mantenere aggiornata la propria copia locale dell'articolo, ma in pratica è stato utile per un coautore ricalibrare periodicamente rivendicando il token per l'intero articolo .

Finché tutti seguivano la disciplina dei token, non c'era bisogno di preoccuparsi dei nomi dei file. Non ci sono state controversie sulla versione, perché la versione più recente della Sezione 5.4 era sempre per definizione nell'email più recente che rilasciava il token per la Sezione 5.4. In particolare, se si ramificava, era tua responsabilità fondere correttamente, non quella dei tuoi coautori.

D'altra parte, i coautori (inclusi sia dottorandi che luddisti di ruolo ) che non seguivano la disciplina dei token si sono trovati coinvolti in un minor numero di documenti in seguito.

Sebbene la mia collaborazione cartacea si sia spostata principalmente su Overleaf + git, in realtà uso ancora questo sistema su le inevitabili ma fortunatamente sempre più rare occasioni in cui ho bisogno di collaborare a un documento di Word con qualcuno che non ha accesso a Word Online o Google Docs.

tl; dr: non farlo a meno che non sia necessario.

Se vuoi evitare le soluzioni cloud e utilizzare la posta elettronica, potresti scegliere un VCS che funzioni offline (cioè è distribuito, come git) e ha il supporto per la posta elettronica (preferibilmente integrato, come git).

Esistono molti modi per impostare un flusso di lavoro di questo tipo, ecco un esempio per git. Essenzialmente: lavori in git come al solito e quando vuoi inviare a qualcuno le tue modifiche puoi usare git send-email ; dopo aver ricevuto un'e-mail contenente le modifiche che vorresti applicare (ad es. forse dopo qualche discussione avanti e indietro in risposta a un messaggio git send-email ) puoi reindirizzare quell'email in un comando come git am per incorporare le modifiche.

git è adatto per l'uso tramite posta elettronica, poiché questo era il suo caso d'uso originale ed è quindi il modo preferito e meglio supportato per usarlo .

Questo non risponde rigorosamente alla domanda, perché si tratta di adottare nessuna convenzione. Come altri hanno detto, di solito è difficile convincere gli autori ad attenersi allo stesso sistema.

Supponendo che tu usi un formato (es. MS Word) che ha una sorta di funzione di "tracciamento delle modifiche", o un formato di testo (es. LaTeX) che puoi diff :

• Consenti agli autori di rinominare i file nel modo che preferiscono
• Una persona (forse in modo non ufficiale) si assume la responsabilità di mantenere una sorta di continuità del documento (cioè mantenere la struttura e il flusso OK)
• Se le versioni del documento divergono, questa persona utilizza la funzione "tiene traccia delle modifiche" per rimetterle insieme
• E poi invia il risultato via e-mail a tutti dicendo "Ho incorporato le modifiche di tutti"
• Alcuni autori non lavoreranno subito su questa versione, specialmente se stavano scrivendo qualcosa o stavano lavorando a stretto contatto con qualcun altro
  • Ma alla fine lo faranno perché non non deve essere lasciato fuori dal giro
  • Nel frattempo il "manutentore" continua ad aggiungere le nuove modifiche al documento "principale"
  • La chiave è che non hanno bisogno di fare alcun lavoro per passare alla versione master.

Autori che non sono disattivati facendo le proprie cose saprà quale versione scegliere (quella che dice "le modifiche di tutti sono qui!")

Questo ha molti altri vantaggi come far risparmiare tempo alla maggior parte degli autori e cercare tra le email, eliminando il pericolo di si perdono i cambiamenti, si sottolineano gli autori sui problemi di continuità e si ha qualcuno che guarda il quadro generale del documento e può discuterne con altri autori.

Una combinazione di "data modificata più iniziali" potrebbe essere d'aiuto, magari combinata con un'abbreviazione di giornale se viene seguito un modello, ad es. "Nature 12-12 BH". Personalmente, trovo le date più facili da monitorare rispetto ai numeri di versione. In ogni caso va evitata a tutti i costi la biforcazione delle versioni.

Se Github / Dropbox / OneDrive ecc. non sono un'opzione, potrebbe esserci un editor LaTex online come Overleaf, in cui ogni collaboratore può lavorare su una singola versione del documento. Un'altra soluzione sono i collegamenti per il download inviati tramite posta elettronica, poiché non è necessario disporre di un account per accedere a un file (questo ha il vantaggio della proprietà e del monitoraggio del processo ma include più problemi). Se la mancanza di Internet è un problema, non riesco a pensare a qualcosa.

tl; dr: Secondo la mia opinione personale, l'opzione migliore è mantenere il nome del file sempre.

Ecco il mio ragionamento. Il nome del file ci dice a quale scopo serve il documento, quali informazioni contiene. Le meta informazioni (chi è l'autore, quando è stata effettuata l'ultima modifica) vengono salvate nelle proprietà del file o in campi speciali all'interno del file stesso. La cronologia delle modifiche viene tradizionalmente mantenuta utilizzando un sistema di controllo della versione (VCS).

Nel tuo caso, utilizzi la posta elettronica come VCS. Le e-mail hanno un timestamp e il tuo client di posta ti consente di ordinare le e-mail in base a questa data. Le e-mail forniscono anche informazioni sull'ultimo autore. Se le persone inviano le loro modifiche rispondendo all'e-mail con la versione da cui è stata effettuata la modifica, il client di posta mantiene l'intero albero delle modifiche, proprio come git, permettendoti di trovare un genitore per ogni versione. Un albero di email è un equivalente diretto di un albero git. Potresti voler creare un filtro per mettere tutte le email con questo file allegato in una cartella speciale per separarle dal resto delle tue comunicazioni. Oltre a questo, l'email è già un minimalista e incompleto (nessuna unione automatica per esempio), ma funzionante VCS.

Dato che hai già un VCS, modificare i nomi dei file per codificare le stesse informazioni non è necessario e scomodo e dovrebbe essere evitato.

PS: E va da sé, l'email è molto VCS più povero rispetto ad es git, quindi dovresti almeno offrire ai tuoi collaboratori di provare a utilizzare un sistema migliore per la collaborazione.

Se devi condividere i file in questo modo (e spesso devi solo farlo, nonostante i molti meravigliosi strumenti di controllo della versione, condivisione di file nel cloud e strumenti di modifica collaborativa disponibili), suggerisco un formato come mainfilename-timestamp-initials .

Ad esempio, cure_for_cancer-202005011030-jb.tex , dove il timestamp è per le 10:30 del 1 maggio 2020, che semplifica l'ordinamento di più versioni dello stesso file lessicograficamente (cioè in base al nome del file). Ma ovviamente hai la sfida di convincere i collaboratori a seguire la stessa convenzione.

Nella mia esperienza, il problema più grande è che il metadato "ultima modifica" del file spesso finisce per riflettere l'ora in cui è stato "salvato / scaricato l'ultima volta". Ciò significa che stabilire dove si inserisce in un flusso di lavoro può essere un incubo.

Le mie soluzioni, che non richiedono competenze informatiche (lavoro in una disciplina umanistica, quindi non si può presumere che tutti si sentano a proprio agio nell'usare i suggerimenti in altre risposte), sono le seguenti:

• inserisci manualmente le date delle revisioni recenti e i monogrammi dell'autore associati nell'intestazione della pagina (ad esempio: "JB 31/04 / 2019; modificato JRW 02/05/2019; JB commenta 03/05/2019 ") - questo rende le informazioni facili da trovare e assicura che siano incluse in ogni pagina di una stampa (sì, mi piace commentare le versioni di annotare una stampa a mano!); e

• tutti i nomi di file iniziano con la data della versione in aaaammgg formato ( es: "20190503_JB_comments_re_20190502_JRW_Methodology"), al fine di facilitare l'ordinamento rapido e l'identificazione univoca delle versioni recenti sui filesystem del computer.

Vorrei provare il controllo delle versioni semantico, come suggerito dalle persone che gestiscono Github.

In breve: aggiungi una serie di tre cifre alla fine del nome del file. Ad esempio: myfile-1.0.0.txt. Quando qualcuno te lo rimanda, qualunque cosa con cui risponda, puoi contrassegnare la tua prossima versione con un identificatore in quel formato che chiaramente conta come numericamente maggiore.