Domanda

Ho un numero di utenti non tecnici che condividono tutti una serie di file di progetto.L'ideale sarebbe che utilizzassero il controllo della versione, ma penso che sia subversion che git siano troppo tecnici per il personale d'ufficio non tecnico.

Esiste un software di controllo del codice sorgente distribuito che funzionerebbe bene per le persone normali?

È stato utile?

Soluzione

Se il controllo del codice sorgente è troppo tecnico, possono essere utilizzati Sovversione con WebDav.

Le persone meno tecniche salveranno semplicemente i file normalmente da qualunque applicazione utilizzino, senza preoccuparsi/pensare al controllo del codice sorgente.Ottengono il vantaggio del controllo automatico delle versioni senza fare nulla.

Ogni volta che hanno bisogno di più funzionalità possono imparare a usare TortoiseSVN per visualizzare le differenze, ripristinare la vecchia versione creata automaticamente per loro, ecc...

Dal libro sulla sovversione:

Poiché molti sistemi operativi dispongono già di client WebDAV integrati, il caso d'uso di questa funzionalità rasenta il fantastico:immagina un ufficio di utenti ordinari che utilizzano Microsoft Windows o Mac OS.Ogni utente "monta" il repository Subversion, che sembra essere una normale cartella di rete.Usano la cartella condivisa come fanno sempre:aprire file, modificarli, salvarli.Nel frattempo, il server esegue automaticamente il controllo delle versioni di tutto.Qualsiasi amministratore (o utente esperto) può comunque utilizzare un client Subversion per effettuare ricerche nella cronologia e recuperare versioni precedenti dei dati.

Altri suggerimenti

Hai provato Tartaruga SVN?Non riesco a immaginare che il controllo del codice sorgente diventi molto più facile da usare.

Sembra più un caso d'uso per uno strumento collaborativo come Campo base, SpiceBird, o SharePoint di "Controllo della fonte". Tali strumenti hanno lo stesso obiettivo del controllo della fonte ma sono più orientati verso le cose del tipo di documento di parole e gli utenti corrispondenti.È un elemento in più che il personale IT deve mantenere sul server, ma elimina anche la possibilità che l'assistente di qualcuno cancelli il tuo codice.

Se hanno solo bisogno di modificare raramente i file di Office un utente alla volta, ottieni i file su una condivisione di rete con le autorizzazioni appropriate ed eseguine il backup durante la notte.Active Directory li avviserà se qualcuno lo ha già aperto.

Se è più complicato del semplice ufficio, considera Sharepoint.Penso che SVN sia troppo complicato soprattutto perché i conflitti e i confronti di file binari, ad es.i vecchi documenti Word non funzionano davvero.

Vorrei provare con Mercurial TartarugaHG per l'integrazione di Explorer.

È abbastanza facile da usare che potrei senza problemi:

  • insegnatelo a un collega non così esperto di computer per scrivere testo insieme.
  • guida telefonicamente un amico attraverso l'installazione di Mercurial (TortoiseHG), la creazione di un repository e la configurazione per lavorare insieme utilizzando repository push (suo) e pull (mio) separati - dopo averlo installato solo una volta su una macchina Windows (eseguo solo GNU/ Linux).

E poiché è completamente distribuito, non possono danneggiare il tuo repository quando danneggiano il loro: puoi semplicemente decidere di non eseguire il pull delle loro modifiche o di eseguire solo il pull delle modifiche valide (ad esempio evitando questi enormi file binari che i principianti tendono a mettere sotto il controllo della versione ).

Da allora sono passato a gestire anche tutti i miei siti Web statici tramite Mercurial (e un hook push-upload che carica automaticamente il sito Web sul mio server FTP, quindi non devo più preoccuparmene).

Penso che la soluzione migliore sarebbe quella di convincere tutti a utilizzare direttamente il sistema di controllo della versione.Se utilizzi una piattaforma Windows, TortoiseSVN sarebbe il mio consiglio.

Se usare TortoiseSVN direttamente è troppo difficile, ho avuto buone esperienze con la configurazione di una condivisione di file Samba in cui sono archiviati tutti i documenti del progetto e la sincronizzazione automatica con Subversion.Perdi i vantaggi derivanti dalle persone che scrivono commenti sui loro commit, ma in molti casi la cronologia delle versioni automatica è meglio di nessuna cronologia delle versioni.In questo modo le persone coinvolte non devono nemmeno essere a conoscenza del tracciamento della versione, purché salvino i loro documenti nel posto giusto.La frequenza con cui è necessario eseguire la sincronizzazione dipende dalla frequenza con cui vengono modificati i documenti, ma nel mio caso era adeguata una sincronizzazione ogni 24 ore.

Nota:Per implementare ciò ho dovuto scrivere uno script personalizzato che estraesse l'ultima versione dal repository, la confrontasse con la copia locale e rilasciasse svn (O cvs) comandi per aggiungere, rimuovere e aggiornare eventuali file modificati.Non sono sicuro che esista una soluzione generale (open source) per farlo, ma non penso che dovrebbe essere troppo difficile implementarla comunque da solo (ho scritto un semplice script per farlo in poche ore).

Attualmente sto esplorando la misura in cui SharePoint può fornire un controllo della versione affidabile ma non tecnico in un contesto simile.Il risultato preliminare è "meh".Anche nel caso in cui si giunga ad una conclusione, diventa già chiaro che il controllo delle revisioni richiede un cambiamento piuttosto importante nell'atteggiamento degli utenti nei confronti della gestione dei documenti.

Ora, se questo fosse per i team che utilizzano Apple Mac, cosa che presumo non sia, lo consiglio vivamente Versioni, che è un client SVN estremamente intuitivo.Questo è il primo e unico software in cui ho visto il controllo di revisione e i suoi cambiamenti di paradigma adottati facilmente da non programmatori.

Ho creato un howto per la risposta subversion+webdav:

http://timwise.wikispaces.com/document-versioning

Hai provato il version cue di Adobe?Questo non è open source/gratuito ma potrebbe essere più facile da usare per l'utente finale.

http://www.adobe.com/products/creativesuite/versioncue/

Se Subversion con TortiseSVN è troppo complesso - e potrebbe esserlo, poiché il controllo della versione è un paradigma completamente diverso da Apri, Modifica, Salva - allora potresti avviarli con un controllo della versione manuale molto più semplice:

mioDocumento-20080908-beverlyd.doc

È semplice, facile da capire e puoi scrivere uno script che ogni notte o settimana archivia tutte le versioni precedenti in modo che possano vedere solo l'ultima o due versioni.

Se qualcuno vuole vedere le differenze, insegnagli le differenze.

-Adamo

"File di progetto" è potenzialmente vago: se i file in questione non sono principalmente file ASCII e sono documenti Word o cosa vuoi, non sono sicuro che gli strumenti tradizionali di controllo del codice sorgente funzioneranno davvero.

SVN et.al.supporterà felicemente i file binari, ma se lo usi solo per questo, non otterrai davvero la maggior parte delle funzionalità utili e generalmente finirai per confondere gli utenti non tecnici.SVN (e git, ecc.) sono strumenti progettati per i programmatori: se stai solo cercando un buon modo per gestire le revisioni dei documenti e mantenere una cronologia, immagino che ci siano strumenti migliori per la tua particolare piattaforma (anche se non lo so). non ne so abbastanza per consigliarne uno in particolare).

Detto questo, se sono per lo più file ASCII, sospetto che TortoiseSVN sia la soluzione migliore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top