Passare da SVN a & # 8230 ;?

StackOverflow https://stackoverflow.com/questions/813663

Domanda

Attualmente sto lavorando in un team in cui stiamo " usando " un repository di sovversione. Dico "usando", perché in realtà tutti stanno semplicemente modificando i file direttamente su un server tramite condivisioni samba, mentre ogni tanto il nostro architetto si impegna da quel server con le nostre modifiche, che vengono poi trasferite ai server.

Quindi in pratica ci stiamo perdendo la possibilità di ricevere messaggi di commit significativi da diversi utenti e di essere in grado di impegnarci tutte le volte che vogliamo.

Ho cercato di suscitare un po 'di interesse nei confronti dei sistemi distribuiti e di come il flusso di lavoro che abbiamo sembra possa essere impostato molto bene con qualcosa come git (ci impegniamo sulle nostre macchine locali e poi spingiamo i cambiamenti per lui recensione) ma non sento di avere abbastanza esperienza con Git. Gran parte della mia esperienza DVCS è stata con mercurial.

Tutti lavorano praticamente in un ambiente Windows usando tortoisesvn, ed è così che sono abituati a interagire con il sistema, ma a volte usano PuTTY per lavorare su uno dei server Linux e sanno come fare una riga di comando commit.

Qual è la strada da percorrere, ho visto parte del lavoro svolto per creare gateway tra SVN e alcuni DVCS, qualcuno ha esperienza nell'impostazione e nel lavoro in un tale ambiente?

Che ne dici di migrazioni su larga scala da SVN a un DVCS?

È stato utile?

Soluzione

Se la tua squadra non riesce a capire bene come usare la sovversione, non so come riuscirai a fargli capire git. Soprattutto perché sono nella mentalità di "permettono a tutti di lavorare nella stessa copia di lavoro", avranno difficoltà a comprendere un sistema di controllo della versione distribuita.

Nella mia esperienza, per usare svn-git, devi sapere come usare git E devi sapere come usare svn. Consiglio di insegnare loro a usare correttamente svn.

Altri suggerimenti

C'è un motivo per cui non vuoi semplicemente conservare il tuo repository SVN e usarlo nel modo in cui SVN è destinato a essere utilizzato?

Perché non fare semplicemente il check-in e l'unione di tutti, utilizzare le filiali, ecc.? Perché passare a una configurazione del repository?

Sembra che il problema che stai descrivendo abbia principalmente a che fare con procedure e protocolli adeguati per il commit del codice. ottenere un prodotto diverso non cambierebbe il modo in cui le persone lavorano. devi educarli prima. mostrare loro come fare le cose meglio.

In un'altra nota, non ho capito come usi tortoiceCVS per l'interfacciamento con SVN.

Per me sembra che la scelta di un sistema di controllo della versione non sia il problema. Quello che devi fare è convincere l'architetto che deve elaborare alcune politiche sane per utilizzare un sistema di controllo delle revisioni.

Il tuo attuale sistema svn sarebbe perfettamente adeguato; consentire agli utenti di creare rami se è necessario mantenere il tronco pulito. L'architetto può unirli come deve.

Ora, potresti spostarti da un DVCS e ci sono buone ragioni per farlo. Ma se il team non è abituato a utilizzare un client / server rcs, questo potrebbe rivelarsi impegnativo. E potresti usare git o hg localmente ma questi sono soluzioni alternative a un utilizzo rcs sostanzialmente rotto. Invitare tutti a utilizzare prima svn sarebbe il mio suggerimento.

Modifica dei file su una condivisione samba ?? Sul serio?!

git-svn è sicuramente la tua scommessa migliore qui. Sarai in grado di utilizzare tutto il controllo della versione locale e modificare le funzionalità di revisione di git, ma alla fine puoi eseguire il push up di "final" check-in nel tuo repository svn esistente.

Questo ha l'effetto fantastico di essere in grado di far bagnare i piedi la tua squadra con git un po 'alla volta (sia perché puoi provare prima di acquistare sia perché puoi ancora utilizzare tutti i processi di distribuzione / manutenzione esistenti sviluppati utilizzando SVN).

C'è anche un buon corso di crash sulla sintassi git per utenti svn che tu può utilizzare per velocizzare la tua squadra.

Il tuo problema non è SVN stesso ma non lo utilizza correttamente.

Come potrebbe dire Steve Yegge: TOOOOOLS

Come dicono gli altri, se non riesci a farli usare svn, non useranno un vcs distribuito.

Usano gli IDE? In tal caso, trovare plug-in per l'IDE che semplifichino l'utilizzo di svn. Quindi possono fare clic con il pulsante destro del mouse su un file o una cartella nell'IDE e effettuare il check-in. Se si semplifica l'uso del controllo del codice sorgente su una copia locale piuttosto che l'accesso diretto ai file centrali, è possibile che si verifichi una possibilità. Quindi è possibile utilizzare TortoiseSVN per attività più complesse.

Alcuni link ai plug-in SVN per gli IDE più diffusi per iniziare:

E ecco un elenco di plugin IDE dal sito Web di Subversion.

hg è anche abbastanza bravo a lavorare con Subversion - vedi https: // www. mercurial-scm.org/wiki/WorkingWithSubversion . Il team di sviluppo principale di Python ha appena deciso di passare da Subversion a Mercurial (dopo una lunga discussione e un periodo in cui sono stati considerati anche git e bazaar); in uno sviluppo indipendente, il servizio di hosting gratuito di code.google.com per progetti open source ha aggiunto il supporto hg al supporto di lunga data per svn.

sia git che bazaar hanno un buon supporto per svn. infatti git-svn è maturato abbastanza negli ultimi mesi.

prova git, perché un DVCS è davvero bello e non è così difficile come lo fai sembrare

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