Qual è il modo più efficace / efficiente per sviluppare un'applicazione con più persone senza controllo del codice sorgente?

Introduzione alla mia situazione

Lavoro per una piccola società di sviluppo web. Abbiamo un team di quattro sviluppatori ASP.NET, incluso me. Quasi tutti i nostri progetti (> 98%) sono progetti individuali che richiedono circa 1-4 settimane per essere completati. Non utilizziamo il controllo del codice sorgente o della versione. L'unica cosa che abbiamo è una cartella condivisa su un server locale che contiene la fonte più recente (== la fonte dell'applicazione live) di tutti i progetti.

Nelle rare occasioni in cui dobbiamo lavorare sullo stesso progetto con più di una persona, usiamo ... Beyond Compare. Una o due volte al giorno gli sviluppatori si chiedono l'un l'altro se hanno una versione che si compila e quindi sincronizzano il loro codice usando Beyond Compare. Quando solo due persone stanno lavorando a un progetto, questo funziona "piuttosto bene", ma non appena un terzo sviluppatore entra nel processo, diventa un ingestibile pezzo di spazzatura. Soprattutto quando tutti iniziano a modificare il database.

Io (e uno o due dei miei colleghi sviluppatori) abbiamo già detto diverse volte al mio capo che dovremmo iniziare a utilizzare una qualche forma di controllo del codice sorgente e della versione come Git, Mercurial o TFS (il nostro capo è molto interessato a Microsoft). Sfortunatamente, il mio capo non vede il vantaggio di passare a un sistema di controllo della versione e della sorgente, perché ai suoi occhi tutto funziona bene ora e non vuole investire tempo e denaro nella creazione di un nuovo sistema e assicurarsi che tutti sa come usarlo. Anche dopo che gli ho spiegato i vantaggi (come la collaborazione semplificata, diverse versioni di un'applicazione, un modo più sicuro per cambiare codice, ...) per lui, non pensa ancora che sia qualcosa di cui abbiamo bisogno.

Dei quattro sviluppatori, solo due (incluso me) hanno esperienza con il controllo del codice sorgente (Git). E quell'esperienza è molto limitata. So come clonare un repository Github sul mio computer, apportare alcune modifiche, eseguirne il commit e rimandarlo su Github. Questo è tutto.

Spiegazione del mio problema / preoccupazione

Tra qualche settimana inizieremo a lavorare su un progetto piuttosto grande per i nostri standard. Probabilmente ci vorranno 2-3 sviluppatori alcuni mesi per completarlo. Sarò il responsabile del progetto (project manager e lead developer) e sarò responsabile di tutto. Ho avuto la mia parte di problemi con il nostro approccio Beyond Compare e non voglio intraprendere questa strada con questo grande progetto che sarà la mia responsabilità.

Dal momento che dubito che saremo in grado di

• configurare il nostro server Git,
• insegnare a tutti a lavorare con Git e
• impiega Git con successo in questo grande progetto,

Sono interessato se qualcuno di voi conosce alcuni buoni modi per consentire a più persone di collaborare allo stesso progetto senza utilizzare il controllo del codice sorgente o della versione.

Aggiornare

Ringrazio tutti per le risposte e i commenti. Ecco il piano:

1. Avere un incontro con gli sviluppatori per assicurarsi che tutti i tecnici sentano allo stesso modo l'implementazione del controllo del codice sorgente. Faremo un punto più forte quando tutti sono dietro di esso.
2. Presenta l'idea al capo e digli che abbiamo davvero bisogno del controllo del codice sorgente.
3. Implementalo il prima possibile.

Ti preghiamo di dedicare un giorno all'installazione del controllo versione e di insegnare a tutti sul progetto a usarlo. Non è così difficile. Personalmente non ho usato Git, ma ho installato e usato altri sistemi di controllo della versione e non sono così difficili da far funzionare. Assicurati di sceglierne uno che si integri con il tuo ambiente di sviluppo. Questo renderà l'utilizzo praticamente senza soluzione di continuità.

Questo non sarà tempo perso.

Il tempo che si perde quando sovrascrive qualcuno o eliminazioni del codice vi costerà molto di più.

Se non si dispone del controllo della versione, si impiegherà anche una quantità eccessiva di tempo per eseguire il backup del progetto e preoccuparsi di quale versione hanno tutti e quale versione si trova sul server, ecc.

Se devi convincere il tuo capo a fare una stima del tempo necessario per impostare e monitorare qualsiasi soluzione di controllo non versione e aggiungere il costo della riscrittura di alcuni giorni di lavoro perso. Non dimenticare di aggiungere il costo della fusione manuale delle modifiche di 3 sviluppatori che lavorano sullo stesso file di origine e il costo aggiuntivo di sbagliare l'unione. Un buon controllo della versione ti dà questo gratuitamente

Quindi confrontalo con il costo di ottenere il controllo della versione - zero (se vai open source) e configurarlo - 3 giorni lavorativi.

Non dimenticare che un errore successivo nel progetto costerà più di uno all'inizio. Se devi rifare l'intero progetto a causa di un errore che chiunque può fare, questo costerà molto di più del semplice tempo di riscrittura, potrebbe costare al tuo capo la reputazione della sua azienda.

Se condividi la fonte su una cartella, puoi condividere anche i repository. Il capo non lo saprà tranne che c'è una cartella .git lì dentro.

Non dovresti mai chiedere l'autorizzazione per svolgere correttamente il tuo lavoro - Seth Godin.

Imposta il controllo del codice sorgente, impara come usarlo e non dirlo al tuo capo. Normalmente non propongo di disobbedire alla direzione, ma in questo caso il tuo capo è stupido. Se pensi davvero che git impiegherà troppo tempo ad imparare, allora inizia con un sistema di controllo versione più semplificato come svn: non fa tutte le cose interessanti di Git, ma è ancora più facile ottenere una comprensione di base.

Non aspettare fino a quando non sei nel mezzo e seriamente nei guai prima di implementare qualcosa. Fallo e finisci il lavoro.

Modificato per aggiungere: la tua domanda è "come posso fare il controllo del codice sorgente senza usare un sistema di controllo del codice sorgente". Hai riconosciuto la necessità e penso che tutti qui ti stiano davvero dicendo la stessa cosa: non c'è modo sano di fare il controllo del codice sorgente senza un sistema di controllo del codice sorgente.

Ho solo il tuo sommario da seguire, ma da quello sembra che il tuo capo stia discutendo tempo e denaro e tu stia discutendo di superiorità tecnica. Devi fare una discussione su tempo e denaro. Impara come fare le cose e tieni traccia per un po 'del tempo che potrebbe salvare, quindi presenta un registro al tuo capo con voci come "28/03/2011 ha dovuto attendere 30 minuti affinché Joe tornasse a una build compilabile così potremmo fare un merge, il comando git merge contro il suo ultimo commit sarebbe stato di circa 5 secondi "con un bel totale in fondo.

Se l'addestramento e la configurazione di un server sono blocchi stradali aziendali, ci sono un numero infinito di modi per impostare un flusso di lavoro git, incluso avere un solo membro del team che utilizza effettivamente Git, con cartelle condivise per il "server".

Chiedi ai tuoi colleghi di copiare il loro codice in una determinata cartella condivisa ogni volta che è opportuno condividere. Puoi tenere un repository per ognuno di essi e fare tutto il materiale di controllo del codice da solo, e lentamente trasferire sempre più responsabilità sul controllo del codice sorgente man mano che diventi abbastanza sicuro da addestrarli. Questo è ben lungi dall'essere il modo ideale per farlo, ma rispetto a quello che hai ora, anche questo ti farà risparmiare tempo sulle fusioni. È più facile convincere il tuo capo con meno curve di apprendimento del team e ottieni tutti i vantaggi di rollback e versioning che desideri.

Non faccio molto lavoro sul database, ma per quanto ne so l'unione delle modifiche allo schema del database non è gestita molto bene dal controllo del codice sorgente. Se tali fusioni sono difficili, è possibile prendere in considerazione una modifica del processo in cui tutte le modifiche al database passano attraverso un singolo gatekeeper.

Questo è folle. Dovresti usare un VCS anche se lavori da solo. Non utilizzare un VCS in un'azienda dovrebbe essere vietato. Fallo e basta. Proprio adesso! Davvero ... Non hai bisogno di cose avanzate fin dall'inizio. GitHub e GitLab sono molto semplici da usare, ma sono sicuro che puoi trovare altri servizi di hosting compatibili con Windows se il tuo capo insiste (anche se non è difficile da configurare e utilizzare Git su Windows).

Il pensiero che chiedi è impossibile . Se più persone stanno lavorando allo stesso progetto senza utilizzare alcun controllo del codice sorgente, avrai rapidamente molti problemi e, poiché sarai lo sviluppatore principale, dovrai affrontarli.

Dalla mia esperienza personale, lavorare su un progetto senza controllo del codice sorgente diventa impossibile da due sviluppatori . Non tre. Non quattro. Due. Probabilmente potresti essere in grado di gestire la situazione con due sviluppatori in circostanze eccezionali : se quegli sviluppatori sono molto organizzati e professionali, se interagiscono bene, se possono scambiare facilmente (quindi si trovano nella stessa stanza alle stesse ore, ogni tempo) e se sono in grado di evitare errori umani (modificando per errore il file che è stato modificato da un'altra persona nello stesso momento, quindi cancellando le modifiche apportate da questa persona).

Nel mio caso, è stato sempre più o meno un disastro quando si trattava di far partecipare due persone a un progetto senza controllo della versione. Nel migliore dei casi, una persona stava inviando i file modificati alla seconda e questa seconda utilizzava uno strumento diff per applicare manualmente le modifiche. Nel peggiore dei casi, una persona ha rintracciato le modifiche che stava facendo, quindi le ha riapplicate ogni volta che la seconda persona ha modificato il codice sorgente. Risultato: un'enorme perdita di tempo, denaro e produttività.

Ora, dal mio punto di vista e dalla mia esperienza, vedo tre soluzioni al problema che hai:

• Installa un controllo versione che è facile da usare . Prima installavo CollabNetSubversion come server SVN, è abbastanza veloce e facile da installare, se non ti importa nulla della sicurezza . Se si utilizza Visual Studio, AnkhSvn potrebbe essere installato per consentire agli sviluppatori di aggiornare / eseguire il commit del codice sorgente facilmente da Visual Studio.

• Convinci il tuo capo che il test di Joel è stato scritto da una persona che conosce molto bene il suo lavoro e che se il test di Joel suggerisce di avere un controllo della versione, c'è una buona ragione dietro. Dopotutto, può anche decidere che gli sviluppatori non hanno bisogno di un IDE / strumenti di evidenziazione della sintassi per scrivere il codice. Blocco note di Windows va bene, no? Inoltre, perché avere accesso a Internet? Tutto ciò di cui abbiamo bisogno è un PC molto, molto vecchio con Windows 3.1.

• Esci da questa compagnia , dato che ho dei dubbi sul fatto che tutto tranne il controllo della versione sia perfetto e professionale lì.

Non usare un VCS su nessun progetto più grande perché non vuoi investire il tempo di crearne uno è come fare un lungo viaggio a piedi nudi, perché non vuoi investire il tempo di mettere le scarpe.

Qualsiasi VCS è ordini di grandezza meglio di non averne affatto.

Un modo estremamente semplice per configurare un VCS è ottenere TortoiseSVN (poiché sembra che tu stia usando C #, suppongo che tu sia su Windows). Si crea un repository in una cartella locale che si sceglie (spostarsi su di esso, fare clic con il tasto destro del mouse> TortoiseSVN> Crea repository qui). Condividi questa cartella nella tua rete (dovrebbe preferibilmente essere su un computer, che è sempre disponibile) ed effettuare i checkout con l'URL file://computername/path/to/that/repository. Download escluso, l'installazione non richiede più di un minuto.

La tua risposta è un semplice link al tuo capo ... invia questa pagina a lui / lei ed evidenzia il numero di volte in cui le parole "esci" appaiono dai professionisti.

Mentre la parola "stupido" appare probabilmente tante volte, sono certo che il tuo capo non lo è. Non gli è chiaro il valore assoluto di questo. La domanda da porgli è quale domanda relativa al business provocherebbe la stessa risposta (forse un commercialista che suggerisce "Piuttosto non assicurare questo edificio che sei legato al massimo ti farà risparmiare qualche dollaro!")

Il controllo del codice sorgente è necessario solo quando il numero di sviluppatori in un progetto è> 0. Sto iniziando a pensare che si possa dire lo stesso dell'integrazione continua ...

(-:

Dato che siete sviluppatori ASP.NET, suggerirei di voler scegliere Subversion, TFS o Mercurial, ma a dire il vero non importa quale fintanto che andrete con qualcosa. Lo sviluppo senza controllo della versione non ha alcun senso - tanto meno quando gli strumenti sono più o meno liberi di essere distribuiti e il sovraccarico per usarli è minimo.

TFS ti offrirà un incredibile livello di integrazione. DVCS (mercurial o git) probabilmente ti darà la massima flessibilità e capacità. Non c'è una buona ragione per NON farlo.

Se iniziassi da zero sarebbe quasi certamente con Mercurial.

Una volta che hai il controllo della versione, puoi passare a un server di build (TFS, TeamCity) e da lì alla continua integrazione e a quel punto inizi a vincere la mano sul pugno.

Per tornare al punto di partenza:

Sarò il responsabile del progetto (project manager e lead developer) e sarò responsabile di tutto

A destra, sei responsabile in modo che si decide il necessario controllo di versione (perché si fa), si decide che è necessario un server di build (perché si fa), si decide che è necessario disporre di uscita implementabile dal progetto fin dal primo giorno (perché se puoi sempre implementarlo - e quindi facilitare più test) e che l'implementazione sarà altamente automatizzata - questi sono i passi che stai prendendo per garantire il successo del tuo progetto (di cui sei responsabile ...)

Come accennato in precedenza, è possibile inserire un repository nella cartella condivisa che già si possiede. Non è necessario perdere tempo a configurare un server se si utilizza un sistema di controllo del codice sorgente distribuito, come Git, Mercurial o Bazaar.

Ti suggerirei di usare Git, poiché hai già qualche esperienza con esso, o Mercurial, che ha una buona integrazione in Visual Studio.

Se in futuro il tuo capo ti dirà di passare a TFS, è comunque meglio che non avere alcun controllo della versione.

Ai miei tempi di Powerbuilder, avevamo un intero team che lavorava su una suite di applicazioni senza usare il controllo del codice sorgente. Oh, Powerbuilder aveva il controllo del codice sorgente, ma in realtà usarlo era un crapshoot - se PB si arrestava in modo anomalo mentre era stato eseguito il checkout di un file (e si arrestava in modo anomalo un LOT), quel file binario di codice sorgente binario proprietario ora era inaccessibile. Alcuni flag sono stati impostati nel file e nessun'altra copia di PB poteva caricarlo, nemmeno la stessa persona che lo aveva verificato.

Quindi quello che abbiamo fatto è stato piuttosto semplice. "Ehi, Tom, lavorerò su xyz.pbl. Quindi non apportare modifiche". Nel grande schema delle cose, raramente abbiamo avuto problemi.

Supponendo che non puoi convincere la tua squadra ad adottare il controllo della versione o che il tuo capo sia a conoscenza del sotterfugio e insista sul fatto che la squadra si fermi, c'è un approccio tutt'altro che ottimale che puoi adottare.

Installa Git o Mercurial sul tuo computer. Versione tuo lavoro. Quando il team sincronizza il proprio lavoro tramite il processo Beyond Compare, aggiungi le modifiche al tuo repository locale come nuovo commit. Sarai sempre in grado di recuperare una versione di lavoro precedente dal tuo repository locale se la sincronizzazione del team interrompe qualcosa.

L'uso di un DVCS garantisce che non sia necessario disporre di un server e di un processo di installazione complesso. L'installazione di Mercurial e la messa in funzione delle basi non dovrebbero richiedere più di 30 minuti circa.

Non è una soluzione ideale, ma è meglio di niente.

La mia prima reazione a questo è stata che hai già un processo di lavoro ideale senza controllo della versione. Sembra che abbiate tutti un buon modo di gestire la fusione e così via. Dal punto di vista gestionale, questa è apparentemente una buona situazione. Ho incontrato team che usano il controllo versione, ma devono lottare con il processo di sviluppo stesso.

Quindi convincere il proprio capo basando esclusivamente la propria argomentazione sul fatto che il controllo della versione produrrebbe "un processo migliore" è del tutto inutile. Vi è tuttavia un altro argomento molto più importante sul motivo per cui è necessario utilizzare il controllo della versione o del codice sorgente, che può essere facilmente calcolato in denaro. E questo è:

Rischio

Il problema non è che l'uso del controllo del codice sorgente migliora il processo di sviluppo. È più un problema cosa succederebbe se non avessi il controllo del codice sorgente. Quali sono i rischi?

Supponiamo che qualcuno elimini erroneamente una funzione nel codice o in un intero file? Quanto costerebbe riparare? Si spera che qualcuno lo abbia coperto, quindi la correzione è marginale.

Ma cosa succede se nessun corpo aveva un backup del file perso? Quante ore uomo costerebbe fissare? Ciò richiederebbe forse giorni, e può essere facilmente calcolato nella media delle ore uomo. Sarebbe troppo per l'azienda? Questo potrebbe essere risolto in qualche modo più velocemente?

Sì, con una sorta di controllo del codice sorgente. Al contrario: quanto tempo occorrerebbe per impostare il controllo versione e eseguirne il backup? La maggior parte di quelli open source come git o mercurial non impiegano molto tempo a configurarsi. Insegnare alle persone come usarlo non sarebbe così difficile, considerando che sai già come unirti a Beyond Compare e "fare il check-in" in una cartella condivisa. Questo è un costo di installazione una tantum. Queste ore di lavoro sarebbero inferiori a quelle dei rischi? Se questo è vero, l'utilizzo del controllo del codice sorgente dovrebbe essere una priorità.

Finché puoi mostrare un motivo commerciale per cui è utile avere il controllo del codice sorgente e la gestione del rischio sarebbe un fattore così grande, che convincerebbe la maggior parte dei capi.

Utilizzare un sistema di controllo della versione distribuita come git e utilizzare la macchina per cartelle condivise per archiviare il repository di riferimento. Ecco perché:

Ogni clone è un backup

Se il disco rigido del server si arresta in modo anomalo, tutti ne hanno una copia, pronta per essere distribuita su una nuova unità o server. Poiché la tua azienda non prende sul serio il controllo delle versioni, suppongo che potrebbe essere praticamente lo stesso con i backup.

Riferimento comune

Avere un repository principale con un ramo master consente di conoscere la versione che ha l'ultima parola. Questo risolve il "Hai testato le tue modifiche rispetto alla versione di Franck, ma avevi anche quelle di John? E come le hai unite?".

Consegna più comodamente

Il cliente desidera una versione alfa oggi? Bene, puoi verificare se il master è abbastanza stabile e spedirlo. Se non lo è e non hai il tempo di ripararlo, torna indietro nel tempo e ottieni una versione più vecchia ma più stabile. Non puoi farlo se hai solo l'ultima versione.

Torna indietro nel tempo e correggi i tuoi errori

La tua unione manuale ha avuto problemi che hai visto solo dopo alcuni giorni, ma hai già sovrascritto il contenuto delle tue cartelle condivise? Senza un VSC non hai una storia, quindi non puoi facilmente tornare a un punto in cui puoi controllare gli errori che hai fatto e correggerli. Il codice non è come un'immagine, è come un film: si evolve nel tempo. È possibile estrarre un'immagine da un film. Non è possibile estrarre un film da un'immagine.

Individua i bug più facilmente

È apparso un bug ma non l'hai notato davvero al momento dell'introduzione, quindi non è stato possibile correggerlo mentre il codice era "attivo". Ora non sai davvero quale modifica l'ha introdotta, quindi potrebbe provenire da diverse posizioni nel codice. Ci vorranno ore solo per trovare dove cercare. Con git, avresti potuto semplicemente sviluppare un test per dire se il bug si verifica su una versione specifica e usare git bissectper trovare il commit esatto che ha introdotto il bug. Invece di cercare migliaia di righe di codice, ora sai che si trova in quel cambio di 10 righe e puoi mantenere il test nella tua suite di test per assicurarti che il bug non venga più introdotto.

Ogni sviluppatore è responsabile del proprio lavoro

Se sei il capo squadra e non hai VCS, molto probabilmente dovrai fare il lavoro sporco, le fusioni. Se lo fai da solo, probabilmente non sai tutto su tutte le modifiche e potresti introdurre errori. Al contrario, se chiedi sempre alle persone che hanno scritto il codice di riunirsi con te ogni volta che c'è un codice da unire, allora è tempo che non useranno per produrre nuovo codice.

Con un VCS, in un semplice flusso di lavoro, lo sviluppatore deve solo prendersi cura del proprio lavoro e una fonte esterna di cambiamenti: il ramo principale. Potrebbero esserci 1 o 100 persone impegnate nel ramo principale, è lo stesso. Per poter spingere i suoi cambiamenti, dovrà adattarli agli ultimi cambiamenti fatti da altri. Può sembrare che impieghi più tempo a inviare il codice, ma è perché stai anche facendo l'unione che avrebbe comunque impiegato del tempo.

La differenza è che l'unione viene effettuata dalla persona che ha apportato le modifiche, che conosce meglio quel codice perché lo ha scritto.

Chi ha scritto quel codice?

C'è quel bug qui, ma chi ha scritto quella particolare riga di codice? È difficile da ricordare, soprattutto se il progetto dura sette mesi. git blameti avrei detto chi e quando è stata scritta quella riga, così puoi chiedere alla persona giusta, e non c'è "Non ricordo di averlo scritto".

Il progetto sta diventando più grande

Il cliente desidera più funzionalità e sei un team troppo piccolo, avrai bisogno di un altro sviluppatore. Come gestite la maggiore complessità di unione senza un VSC?

Cambiamenti urgenti

Il cliente ha chiamato e chiesto una correzione di bug critica per la produzione, ma al momento stavi lavorando a una nuova funzionalità. Solo git stashper mettere da parte le modifiche o inserirle in un nuovo ramo e spingere le modifiche e sei pronto per iniziare a lavorare sulla soluzione urgente, senza paura di perdere il lavoro in sospeso.

Ha funzionato 10 minuti fa

Stai apportando alcune modifiche localmente e qualcosa che ha funzionato 10 minuti fa ha smesso di funzionare. Senza un VCS fissi il codice o, nella migliore delle ipotesi, fai una copia della versione di riferimento e diff per vedere cosa cambi. Oh aspetta, il riferimento è cambiato da quando ho iniziato a lavorare, quindi non posso più diff. E non pensavo di conservare una copia originale del codice su cui ho basato le mie modifiche.

Con un VCS, fai subito qualcosa di simile git diffe fai la tua modifica rispetto alla versione corretta del codice su cui ti basi.

Devo tenere i miei log di debug

Quindi sei un cattivo ragazzo e non usi la registrazione? Hai dovuto cospargere printfs in tutto il tuo codebase finché non hai trovato tutti quei pezzi di quel brutto bug? Ora ne hai trovato uno, lo hai risolto, ma vuoi mantenere il tuo codice di debug accuratamente preparato per risolvere i problemi rimanenti.

Senza un VCS, è necessario copiare i file, espellere il codice di debug (che può aggiungere alcuni errori di modifica), inviarlo e ripristinare i file di backup. Oh, ma sembra che sia entrato in qualche codice di debug.

Con git, basta git add --patchselezionare le poche righe di codice che si desidera inserire nel commit e si può solo impegnare . Quindi riprendi il tuo lavoro e hai ancora il tuo codice di debug. Non è stato necessario toccare il codice, quindi nessun errore di copia / incolla.

La grande palla di fango

Senza un VCS, le persone lavorano dalla loro parte e ti danno un sacco di cambiamenti, a volte non correlati. Quando c'è troppo codice da controllare, è difficile trovare un bug.

Un VCS ti consentirà di apportare piccole modifiche incrementali e ti darà un registro delle modifiche. Il changelog è essenziale: la gente deve non dire il motivo per cui stanno facendo il cambiamento, non quello che è il cambiamento (la quale domanda è alredy risposta dal codice cambiamento stesso). Questo significa, ad esempio, quando si ispeziona il codice di una nuova funzione, non sarà necessario leggere molte modifiche miste non correlate come correzioni di bug non correlate. Questo aiuta a concentrarsi sul codice che ti interessa.

Se ti do 100 patate 1 per 1, e una è marcia, la troverai immediatamente. Ora, se scarico 100 patate davanti a te e ti chiedo di trovare quella marcia, non è lo stesso compito.

dentellatura

Spero che tu abbia una buona politica di stile di codifica, altrimenti i cambiamenti di rientro ti faranno impazzire se ti unisci a mano. Certo, puoi ignorare lo spazio bianco nelle modifiche (ma non nelle lingue quando conta il rientro, come Python). Ma poi otterrai un codice dall'aspetto strano difficile da leggere.

Sei il capo progetto

Se sei il leader, questo significa che avrai la colpa se le cose non funzionano. Se non riesci a sentirti a tuo agio con la situazione perché il tuo capo non riesce ancora a capire che vale la pena usare lo strumento giusto per il lavoro giusto, almeno mi rifiuto di diventare il leader di un fallimento prevedibile.

Usa dropbox, ha una cronologia delle versioni automatica. Puoi condividere la cartella dropbox tra più utenti.

modificare

È inoltre possibile scaricare il client TortoiseSVN e creare "repository locale" sull'unità di rete. Quindi le persone possono controllare il codice sorgente in base alla posizione della cartella di rete.