Alternative al controllo versione professionale [chiuso]

Stiamo collaborando con alcuni non programmatori (scrittori) che hanno bisogno di contribuire a uno dei nostri progetti.

Ora non gli piace l'idea di usare Git (o qualsiasi altra cosa) per la versione che controlla il loro lavoro. Penso che ciò sia dovuto al fatto che semplicemente non trovano utile avvolgere la testa attorno ai concetti contorti del controllo della versione. (quando li ho introdotti per la prima volta alla ramificazione e alla fusione, sembravano offenderli.)

Ora, non siamo in grado di educarli o convincerli ad usarlo. Stiamo solo cercando di trovare alternative in modo da ottenere tutto il loro lavoro versionato (che è quello di cui abbiamo bisogno) - e ottengono un flusso di lavoro semplice e si concentrano su ciò che fanno.

Ho avuto alcune idee ...

• di 'loro di salvare il loro lavoro come file separato ogni volta che fanno delle modifiche non banali, e poi usano un diff dalla nostra parte per tenere traccia delle modifiche.
• scrivere un programma (in Python) che implementa le "pietre miliari" in CSSEdit in qualche modo.

Informazioni sul progetto:

È un sistema di elaborazione del linguaggio naturale (scritto in C + Python). Abbiamo assunto alcuni scrittori per preparare input per il sistema in diverse lingue. E mentre evolviamo il software, avremmo bisogno di quegli scrittori per apportare modifiche ai loro input (articoli). A volte i cambiamenti sono molto piccoli (una o due parole), altre volte grandi.

Il motivo per cui dobbiamo controllare la versione di tali modifiche è perché ogni piccola / grande modifica nell'input ha il potenziale per cambiare drasticamente l'output del sistema.

quando li ho introdotti per la prima volta alla ramificazione e alla fusione, sembravano offenderli

Ciò è probabilmente dovuto al fatto che le ramificazioni e le fusioni sono concetti avanzati e infinitamente meno utili che semplicemente per tenere traccia delle modifiche.

Quindi perché non spiegare solo "commit" (salva) e "aggiorna"? Due concetti davvero semplici . Sono sicuro che puoi spiegarlo in meno di 10 minuti.

Se vuoi davvero usare rami separati e cose del genere, puoi farlo da solo senza coinvolgerli.

Un approccio piuttosto non ortodosso sarebbe usare Dropbox . Chiedi agli autori di salvare i file nella directory di Dropbox e ottieni il controllo delle versioni e il backup gratuitamente. Inoltre non esiste praticamente una curva di apprendimento per gli autori.

Per quanto riguarda git, sembra che alla fine finirai per fornire agli autori le versioni di branch corrette comunque, quindi metti il ​​repository git nel dropbox e gestisci il branching e la fusione per gli autori.

Sinceramente la risposta è nella tua modifica: "Abbiamo assunto alcuni scrittori" - a volte devi solo avere una mentalità sanguinaria ... vogliono i tuoi soldi devono fare quello che vuoi a condizione che ciò che vuoi non sia irragionevole.

L'argomento che esponi è l'argomento che hai già avanzato - dobbiamo essere in grado di fare X, Y e Z per far funzionare il prodotto - e per fare ciò abbiamo bisogno che tu lo faccia. Saremo il più possibile di supporto, ma affinché ciò funzioni (e quindi affinché continui come flusso di entrate per te, scrittore), ciò deve accadere.

Tendo a concordare sul fatto che un'adeguata soluzione basata su Wiki sembrerebbe essere una buona corrispondenza, ma la sfida qui è come trovare un compromesso tra il loro flusso di lavoro e le vostre esigenze.

Ripeto il punto chiave - in modo che il vostro progetto per essere un successo è necessario gli articoli da versionato quindi coloro che lavorano sugli articoli devono giocare secondo una serie concordata di regole, se questo non avviene si sarà ottenere bruciato e per estensione, così faranno gli scrittori.

In precedenza ho dovuto affrontare una situazione simile come questa. Alla fine abbiamo appena designato uno sviluppatore (me) come punto di contatto per il controllo della versione per la terza parte.

La terza parte mi inviava via e-mail un file zip dei propri file di progetto ogni giorno e farei il check-in per loro. Ho impostato uno spazio di lavoro di progetto separato e l'account svn per loro e decomprimevo i file in quell'area di lavoro sovrascrivendo ciò che era lì e quindi eseguivo il check-in con quell'account.

Non è la cosa più divertente da fare ogni giorno, ma a volte è più importante semplicemente fare il lavoro.

Un vantaggio è che mi ha aiutato a rivedere il loro lavoro per assicurarmi che non stessero controllando il codice errato e i dati che avrebbero rotto la build.

SparkleShare è un clone di dropbox basato su git, penso che soddisfi le tue esigenze.

SparkleShare crea una cartella speciale sul tuo computer. È possibile aggiungere cartelle (o "progetti") ospitate in remoto a questa cartella. Questi progetti verranno automaticamente sincronizzati con l'host e tutti i tuoi colleghi quando qualcuno aggiunge, rimuove o modifica un file.

... ecco alcuni esempi di cosa fa bene e meno bene con le faccine:

grande

• Modifica frequente dei file di progetto, come testo, documenti di Office e immagini
• Tracciamento e sincronizzazione dei file modificati da più persone
• Ripristino di un file in qualsiasi punto della sua cronologia
• Prevenire lo spionaggio dei file sul server mediante la crittografia

Non così eccezionale

• Backup completi del computer
• Archiviazione della tua raccolta di foto o musica
• Grandi file binari che cambiano spesso, come progetti di editing video ...

Aggiornamento (novembre 2015) : il progetto sembra essere abbandonato (ultima versione di aprile 2014).

Se è possibile fornire un'area di lavoro preparata con un utilizzo VCS trasparente , utilizzeranno VCS. Non insegnare ai non programmatori ad usare VCS alla maniera del programmatore

Basta trovare l'editor con supporto VCS incorporato, configurarlo e mostrare ulteriori semplici passaggi nelle loro opere.

Solo un esempio: Editplus conosce Subversion, ha la capacità di eseguire operazioni SVN di base all'interno della finestra dell'editor. L'ultimo Editplus può persino usare TortoiseGIT per l'integrazione con Git

Modifica : trovata una soluzione alternativa in qualche modo: EasySVN , che, essendo correttamente configurato, monitora la copia di lavoro ed esegue autocommit e automerge, consentendo di utilizzare qualsiasi strumento di authoring per l'utente finale e qualsiasi formato di documento

Che dire di impostare un WebDAV ?

Gestirà automagicamente la cronologia delle versioni in linea retta per loro. Tutto quello che devono fare è connettersi al server come se fosse un'unità di rete e ogni salvataggio sarà un commit.

documenti Google

Google Documenti potrebbe fare quello che vuoi. File > See Revision Historyti consentirà di tenere traccia delle modifiche.

Hai anche il problema di consegnare i file avanti e indietro gratuitamente; condividi il documento tra tutti.

Infine, è facile da usare; gli autori non devono nemmeno sapere che sta avvenendo il controllo delle versioni.

OS Agnostic

Scrivi un programma Python su cui puoi trascinare e rilasciare un file, quel programma può fare git adde git commite cosa no e non devono mai affrontarlo.

o

Usa un filesystem basato su WebDav che puoi montare sul loro computer e chiedi al server di fare le gitcose in modo trasparente.

OSX / Linux

Scrivi un plugin FUSE basato su Python che prende i file e li impegna a git. Quindi possono semplicemente aprire e salvare in modo trasparente dal filesystem montato. Ci sono alcune risorse FUSE per Windows , ma probabilmente non vale nemmeno la pena ingannarle.

finestre

Potresti scrivere del codice per utilizzare i driver del filtro FileSystem per fare le gitcose in modo trasparente .

Ah, le gioie dei non programmatori si agitano. Suggerirei di creare un ambiente git / mercurial per loro. Di 'loro di salvare tutto in un formato che il repository può gestire. Con tortoisegit o tortoisehg , non hanno bisogno di sapere come funziona il repository. Controllano solo se hanno un punto esclamativo nella directory del progetto, fanno clic con il pulsante destro del mouse sul file in questione e fanno clic su commit. Scrivi una sinossi di modifiche (sono scrittori, vero?) E il gioco è fatto!

Un ulteriore passo nel flusso di lavoro per loro, ma nulla riguardo alla fusione / ramificazione / cose interessanti. L'ambiente pre-costruito è già impostato per essere nel ramo degli scrittori, quindi non vedono il codice. Chiedi a uno script di sincronizzarli automaticamente ogni giorno. Successivamente, dopo che sono stati abituati a eseguire il commit, puoi mostrare loro funzionalità extra. La possibilità di vedere cosa è cambiato quando è così utile da non poterne fare a meno, una volta che lo hai nascosto nel loro flusso di lavoro.

Che dire di Share Point? So che non è popolare nei mondi di sviluppo, ma se i tuoi scrittori usano Windows come sistema operativo funzionerà bene e non sapranno davvero che stanno usando il controllo della versione (un grande vantaggio per il mio lavoro).

Questa soluzione impedisce loro di affrontare qualsiasi cosa che li spaventerebbe molto, in quanto sembra essere sciatto di cose nuove.

Potresti impostare uno strumento che monitora il file system in cui gli autori stanno salvando i loro file e fare un commit automatico ogni volta che effettuano un salvataggio?

Se lo metti su una condivisione di rete potresti fare tutta la configurazione senza coinvolgerli affatto; ma ogni volta che hanno fornito una versione aggiornata per l'utilizzo da parte del tuo team, viene aggiunto a git per te.

Hai visto Plastic SCM. Stanno cercando di renderlo più semplice da usare

Se desideri solo backup con versione, puoi utilizzare Dropbox oppure puoi configurare il servizio di backup di Windows. Oppure puoi installare Crashplan o un altro prodotto simile.

Per il Mercurial DVCS, esiste un'interfaccia utente chiamata EasyMercurial , il cui obiettivo dichiarato è esplicitamente quello di fornire una visione semplice delle operazioni di controllo della versione di base.

EasyMercurial vuole essere:

• semplice da insegnare e da imparare indicativo dell'attuale stato del repository, usando una rappresentazione del grafico storico
  • riconoscibilmente vicino al normale flusso di lavoro da riga di comando per Mercurial coerente su più piattaforme

Non stiamo cercando di produrre il miglior client Mercurial per uno scopo. Incoraggiamo attivamente gli utenti a passare ad altri clienti mentre le loro esigenze si evolvono. L'obiettivo è semplicemente quello di fornire qualcosa di accessibile ai principianti in piccoli gruppi di progetto che lavorano con un repository remoto condiviso.

Consiglierei di provarlo.

Ho dovuto lavorare molte volte con non programmatori (per lo più artisti grafici, e se i tuoi scrittori hanno la minima idea di come gestire i file di lavoro degli artisti, allora sei pronto per ... hmmm .... divertimento .. .). Esistono tre possibili approcci:

1. Fai finta che siano programmatori, cerca di insegnare loro come usare il controllo versione. Questo non funzionerà e avrai combattimenti costanti.
2. Scrivi loro uno strumento molto semplice che afferra la versione corrente e la attacca da qualche parte in modo che possano riavvolgere i file di ieri, se necessario. Questo è possibile, e l'ho fatto per un team di creatori di DVD (creare menu, grafica, cose del genere) molti anni fa con un certo successo: lo strumento che ho scritto era un wrapper con un clic per PkZip (puoi vedere qualche tempo fa) e ha appena compresso la directory di lavoro e chiamato l'archivio per la data + ora.
3. Prendi il controllo di ciò che producono da soli. Chiarire che i loro file devono essere consegnati a un programmatore e diventare parte del progetto solo quando il programmatore accetta i file: il programmatore quindi li controlla nel controllo della versione e il contenuto viene gestito in modo professionale.

Personalmente penso che l'opzione 3 sia la strada da percorrere. Significa un po 'di dolore e irritazione per chiunque debba prendere le consegne dei file e farle controllare, ma molto meno di qualsiasi altra opzione.

Vorrei anche dire, essere consapevoli del fatto che i non programmatori consegneranno i file con qualsiasi vecchio nome di file che si possa pensare. Le convenzioni di denominazione sono stranamente estranee a loro. Ti daranno un file chiamato "Picture" o qualcosa del genere e poi quando dici loro le cose che non vanno, ti darà un file chiamato "Picture_Final", che ha corretto solo circa 3 dei guasti. Quando lo fai notare otterrai un altro file, chiamato "Picture_NewFinal", e poi (se sei fortunato) "Picture_NewFinal2", anche se è possibile che a questo punto eliminino qualsiasi senso di sviluppo storico e lo chiamino "Icona chiave inglese cosa".

Ancora una volta puoi provare a far rispettare una convenzione di denominazione, il che significa dire loro in anticipo come chiamare ogni file, oppure puoi passare ore a decodificare e rinominare ciò che ti inviano. Qui direi che vuoi comunque il foglio di calcolo per il tuo buonsenso, quindi prova a convincerli a seguirlo: semplicemente non essere sorpreso quando non lo fanno.

Spero che aiuti - buon divertimento!

Se c'è qualche possibilità che due di loro debbano lavorare contemporaneamente sullo stesso target E se riesci a gestire tutto il loro lavoro in file di testo, proverei documenti Google condivisi.

Ha una straordinaria capacità multi-editor / collaborazione - di gran lunga la migliore che abbia mai visto. Sono inoltre dotati di versione completa e possono essere esportati come file di testo.

Ma quelli sono due if piuttosto grandi.

Lasciali lavorare in una cartella, salvando i file come al solito.

Una volta al giorno (o settimana, ecc.) Copia il contenuto di quella cartella su backup_dd_mm_yyyy La maggior parte del codice sorgente dei sistemi occupa una quantità banale di spazio dato lo spazio disponibile in questi giorni.

La copia può essere eseguita da te, loro, una terza parte, uno strumento o uno script.

Questo limita la perdita a un giorno, dà una storia, è trasparente per loro.

Non perfetto per entrambe le parti, ma una risposta che cerca di colpire una via di mezzo.