Alternative al controllo versione professionale [chiuso]

when I first introduced them to branching and merging -- they looked like I was offending them

Questo è probabilmente dovuto al fatto che la ramificazione e la fusione sono concetti avanzati e infinitamente meno utili che tenere traccia delle modifiche.

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

Se vuoi davvero utilizzare rami separati e cose del genere, puoi farlo tu stesso senza coinvolgerli con esso.

Un approccio poco ortodosso sarebbe solo utilizzare Dropbox . Chiedere agli autori di salvare i file nella directory dropbox e ottenere gratuitamente il controllo delle versioni e il backup. Inoltre non c'è praticamente alcuna curva di apprendimento per gli autori.

Per git, sembra che alla fine finirai per fornire comunque agli autori le versioni corrette dei branch, quindi basta inserire il repository git nel dropbox e gestire la ramificazione e l'unione per gli autori.

Sinceramente la risposta è nella tua modifica: "Abbiamo assunto alcuni scrittori" - a volte devi solo essere maledettamente intenzionato ... vogliono i tuoi soldi devono fare quello che tu vuoi fornire che quello che vuoi non è irragionevole.

L'argomento che fai è l'argomento che hai già avanzato - dobbiamo essere in grado di fare X, Y e Z per far funzionare il prodotto - e per fare questo abbiamo bisogno di te fare quello. Saremo di supporto come possiamo, ma per farlo funzionare (e quindi per continuare come flusso di entrate per te, lo scrittore) questo deve accadere.

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

Ripeterò il punto chiave: affinché il tuo progetto abbia successo, gli articoli devono essere versionati, quindi chi lavora sugli articoli deve giocare secondo un insieme di regole concordate, se ciò non accade sarà bruciato e, per estensione, anche gli scrittori.

Ho avuto a che fare con una situazione simile come questa prima. Alla fine abbiamo appena indicato uno sviluppatore (io) come punto di controllo di controllo della versione per la terza parte.

La terza parte mi mandava via email un file zip dei file di progetto ogni giorno e io eseguivo il check-in per loro. Ho impostato uno spazio di lavoro del progetto separato e un account svn per loro e decomprimere i file in quell'area di lavoro sovrascrivendo ciò che era lì e quindi effettuare il check-in su quell'account.

Non è stato il più divertente da fare ogni giorno, ma a volte è più importante avere solo il lavoro da fare.

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

SparkleShare è un clone di dropbox basato su git, penso che sia adatto alle tue esigenze.

SparkleShare creates a special folder on your computer. You can add remotely hosted folders (or "projects") to this folder. These projects will be automatically kept in sync with both the host and all of your peers when someone adds, removes or edits a file.

...here's a few examples of what it does well and less well with smiley faces:

Great

• Frequently changing project files, like text, office documents, and images
• Tracking and syncing files edited by multiple people
• Reverting a file to any point in its history
• Preventing spying on your files on the server using encryption

Not so great

• Full computer backups
• Storing your photo or music collection
• Large binary files that change often, like video editing projects...

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

Se puoi fornire lo spazio di lavoro preparato con trasparente VCS, utilizzeranno VCS. Non insegnare ai non programmatori a utilizzare VCS in modo programmatore

Trova l'editor con il supporto VCS integrato, configuralo e mostra ulteriori semplici passaggi nelle loro opere.

Solo un esempio - Editplus sa di Subversion, ha la capacità di eseguire operazioni SVN di base all'interno della finestra dell'editor. Anche l'ultima Editplus può utilizzare TortoiseGIT per l'integrazione Git

Modifica : trovato una soluzione alternativa a modo alternativo: EasySVN , che, opportunamente configurato, monitora la copia di lavoro ed esegue autocommit e automerge, consentendo di usa uno strumento di authoring per l'utente finale e tutti i formati del documento

Che ne dici di configurare un WebDAV ?

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

Google Documenti

Google Documenti potrebbe fare ciò che vuoi. File > See Revision History ti consente di tenere traccia delle modifiche.

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

Infine, è facile da usare; gli scrittori non devono nemmeno sapere che c'è il verificarsi delle versioni.

Agnostic OS

Scrivi un programma Python su cui puoi trascinare e rilasciare un file, quel programma può quindi fare il git add e git commit e cosa no e non devono mai occuparsene.

o

Utilizza un file system basato su WebDav che puoi montare sulla loro macchina e fare in modo che il server esegua la roba git 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 dal filesystem montato in modo trasparente. Ci sono alcune FUSE per le risorse di Windows , ma probabilmente non ne valgono nemmeno la pena .

di Windows

Potresti scrivere del codice per usare Driver del filtro FileSystem fare in modo trasparente la roba git .

Ah, le gioie dei non codificatori. Suggerirei di creare un ambiente git / mercuriale 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 incriminato e fanno clic su commit. Scrivi una sinossi di modifiche (sono scrittori, giusto?) E hai finito!

Un passo in più nel flusso di lavoro per loro, ma nulla di fusione / ramificazione / roba interessante. 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. Più tardi, dopo che sono stati abituati a impegnarsi, puoi mostrare loro le funzionalità extra. La capacità di vedere cosa è cambiato quando è così utile che non sarà in grado di farne a meno, una volta che lo introduci nel loro flusso di lavoro.

E riguardo 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 veramente che stanno usando il controllo della versione (Un grande vantaggio per il mio lavoro).

Questa soluzione inoltre impedisce loro di affrontare qualsiasi cosa li spaventi molto, in quanto sembra che siano ombrosi di cose nuove.

Puoi configurare uno strumento che monitora il file system in cui gli scrittori stanno salvando i loro file e gli fanno fare un commit automatico ogni volta che effettuano un salvataggio?

Se lo metti in una condivisione di rete, puoi fare tutta la configurazione senza coinvolgerli affatto; ma ogni volta che hanno fornito una versione aggiornata per il tuo team da utilizzare sarebbe stata aggiunta a git per te.

Hai guardato Plastic SCM. Stanno cercando di semplificare l'utilizzo di

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

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

EasyMercurial is intended to be:

• simple to teach and to learn indicative of the actual repository state, using a history graph representation
  • recognisably close to normal command-line workflow for Mercurial consistent across platforms

We are not trying to produce "the best" Mercurial client for any one purpose. We actively encourage users to move on to other clients as their needs evolve. The aim is simply to provide something accessible for beginners in small project groups working with a shared remote repository.

Consiglierei di provarlo.

Ho dovuto lavorare con i non programmatori molte volte (principalmente artisti grafici, e se i tuoi scrittori hanno la minima idea di come gestire i file di lavoro come artisti, allora sei pronto per ... hmm ... divertimento...). Ci sono tre possibili approcci:

1. Fai finta di essere programmatori, prova ad insegnare loro come utilizzare il controllo della versione. Non funzionerà e avrai combattimenti costanti.
2. Scrivi loro uno strumento molto semplice che cattura solo la versione attuale e amp; lo attacca da qualche parte in modo che possano riavvolgere i file di ieri, se necessario. Questo è possibile, e l'ho fatto per un gruppo di creatori di DVD (creando menu, grafica, ogni sorta di cose) molti anni fa con un certo successo: lo strumento che ho scritto era un wrapper con un clic su PkZip (puoi vedere che questo era qualche tempo fa) e ha semplicemente compresso la directory di lavoro e chiamato l'archivio per la data + ora.
3. Prendi il controllo di ciò che producono da te. Metti in chiaro che i loro file devono essere consegnati a un programmatore e diventano parte del progetto solo quando il programmatore accetta i file: il programmatore li controlla in controllo di versione e il contenuto è gestito in modo professionale.

Personalmente ritengo che l'opzione 3 sia la strada da percorrere. Significa qualche dolore & irritazione per chi deve prendere le consegne dei file e farli controllare, ma molto meno di qualsiasi altra opzione.

Direi anche che i non programmatori consegneranno file con qualsiasi vecchio nome di file che si possa pensare. Le convenzioni sui nomi sono stranamente estranee a loro. Ti daranno un file chiamato "Immagine" o qualcosa del genere e poi quando gli dici che le cose che non vanno ti daranno un file chiamato "Picture_Final", che ha solo corretto circa 3 dei difetti. Quando lo indichi, otterrai un altro file, chiamato "Picture_NewFinal", e poi (se sei fortunato) "Picture_NewFinal2", anche se è possibile che a questo punto scarichino qualsiasi senso di sviluppo storico e lo chiamino "Spanner Icon" cosa".

Ancora una volta puoi provare a far rispettare una convenzione di denominazione, il che significa dire loro in anticipo che cosa deve essere chiamato ogni file, oppure puoi passare ore a decifrare & rinominare ciò che ti mandano. Qui direi che vuoi comunque il foglio di calcolo per la tua sanità mentale, quindi cerca di convincerli a seguirlo: non essere sorpreso quando non lo fanno.

Spero che ti aiuti: divertiti!

Se esiste la possibilità che due di loro debbano lavorare sullo stesso obiettivo contemporaneamente E se riesci a gestire tutto il loro lavoro in file di testo, proverei a condividere documenti Google.

Ha un'incredibile capacità multi-editor / collaborativa, di gran lunga la migliore che abbia mai visto. Sono anche in versione completa e possono essere esportati come file di testo.

Ma quelli sono due piuttosto grandi se.

Lascia che funzionino in una cartella, salvando i file come al solito.

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

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

Questo limita la perdita ad un giorno, fornisce una cronologia, è trasparente per loro.

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