Dovremmo migrare da svn a Team Foundation Server 2010?

Question

Siamo con 6 sviluppatori e attualmente utilizzo Visual Studio 2008 Professional con SVN e Visual SVN. Non appena verrà rilasciato vs2010, passeremo da vs2008 pro a vs2010 premium.

Tuttavia, se Team Foundation Server dispone di un corretto controllo del codice sorgente incluso in vs2010 premium, è quindi logico utilizzarlo. Ci piace SVN, ma come una stretta integrazione degli strumenti ancora meglio.

Su Internet le informazioni su SVN rispetto a TFS 2010 sembrano essere scarse. Quindi la mia domanda qui.

MODIFICA: Questo video sembra molto convincente. Questo discorso di marketing è reale?

Grazie a tutti per le vostre risposte! Lo apprezzo molto. Un po 'più di informazioni di base.

Questo è il nostro stack corrente; vs2008 pro, Visual SVN, SVN, Jetbrain Teamcity. Il mio problema principale è che utilizziamo molti strumenti di diversi fornitori che si integrano più o meno. A volte di più, soprattutto meno. Almeno ci vuole un sacco di tempo per configurarlo correttamente.

Attualmente non utilizziamo le diramazioni, ma lo vogliamo. Pertanto, dobbiamo configurare SVN da zero (l'abbiamo esaminato attentamente). Lasciatemi riformulare la mia domanda: dovremmo impostare SVN o iniziare a utilizzare TFS?

Answer 1

Se sei un negozio Microsoft, allora TFS è una buona soluzione.

Se Subversion fa tutto ciò che ti serve, aggiusteresti qualcosa che non è rotto?

Devi avere un motivo per cambiare.

[Io uso TFS al lavoro e funziona benissimo, con pochissimi problemi. Uso Subversion a casa, semplicemente perché ho bisogno di meno infrastrutture].

Aggiornamento [2012/05/01]: Se non si è un negozio Microsoft, Git e Mercurial ora sarebbero gli strumenti di scelta.

Answer 2

Dalla mia esperienza, TFS come server di controllo del codice sorgente non è la scelta giusta. Le fusioni sono terribilmente lente, la procedura di check-in è contro-intuitiva e di solito finisce con i file bloccati che solo un amministratore può sbloccare. SVN è molto più maturo, flessibile e veloce.

Answer 3

È più una questione psicologica che tecnica.

Per quanto mi riguarda, non dovresti migrare e rimanere semplice. Avendo solo 6 sviluppatori, non avrai nulla di abbastanza complicato da usare anche una parte delle abilità TFS2010 di alto livello.

VisualSVN è un buon strumento che ti mantiene abbastanza "integrato". E sarà migliorato ancora meglio.

Answer 4

Sono uno sviluppatore Java, ma tutti i miei amici sono .Net, sembrano tutti preferire SVN con Tortoise. SVN è ben supportato anche dalla comunità open source.

Answer 5

Anche se this potrebbe aiutarti a prendere una decisione; Sarei d'accordo con Mitch. Devi avere una buona ragione per cambiare. SVN è molto maturo e affidabile quindi TFS. Inoltre, il TFS è principalmente rivolto alle applicazioni Microsoft, rispetto all'ambito di SVN che va ben oltre TFS.

Answer 6

Penso che TFS sia fantastico.Avere bug tracking e controllo del codice sorgente completamente integrato con Visual Studio è un grande risparmio di tempo. Il protocollo on-the-wire non è troppo chiacchierone, quindi è adatto anche per il lavoro su Internet se/quando necessario.

Ci sono molte altre caratteristiche che sono anche utili, come ad esempio il monitoraggio del portale squadra, statistiche, tracking storie di prova, catturando le uscite di test come parte di un bug (molto utile!), Ecc

Hanno anche supporto completo da riga di comando per script, build automatizzati, un client TFS standalone per l'utilizzo all'esterno di Visual Studio (ad esempio da parte di non sviluppatori) e integrazione facoltativa con strumenti di terze parti come Eclipse per negozi Java/.NET misti.

Lo svantaggio principale è il prezzo, ma se potete permettervelo, penso che sia il miglior sistema disponibile al momento.

Answer 7

Ho usato TFS quando ho dovuto, e odiato ogni minuto di esso. Mi stava troppo nel mio modo, e ci è voluto un tempo per fare qualcosa da remoto. Ma principalmente è solo il mio odio irrazionale. Se uno dei tuoi sei programmatori è come me, avrai un problema. E i programmatori sono più importanti degli strumenti.

Answer 8

SVN esegue il controllo della sorgente. Il suo client predefinito è la riga di comando, ma esistono strumenti GUI.

TFS esegue il controllo del codice sorgente, tracciamento bug/problemi, build automatizzati, reporting per i dirigenti e può curare la calvizie maschile. Il suo client predefinito è Visual Studio.

Se all si desidera il controllo del codice sorgente, allora SVN funziona e perché modificare ciò che non è danneggiato. Se tutto ciò che desideri è una più stretta integrazione in Visual Studio, guarda a Ankh o VisualSVN.

Se si desidera build automatizzati, integrazione continua, controllo di policy e regole, reporting, tracciamento dei problemi e tutto in uno, TFS fa per voi, presupponendo di non avventurarsi al di fuori degli strumenti di sviluppo Microsoft (in genere - ci sono plugin per altri IDE). Puoi ottenere la stessa cosa con altri strumenti FOSS e avvolgerli insieme con del nastro adesivo attorno a SVN e anche questo funziona, non è altrettanto semplice e richiede un investimento maggiore.

Tuttavia, si sta confrontando un sistema di controllo del codice sorgente con uno strumento di gestione del ciclo di vita dello sviluppo. TFS fa il controllo del codice sorgente, ma lo fa molto di più.

Answer 9

Avevo TFS nel mio ultimo client, ora il mio nuovo client ha subversion e il suo terribile. Nessuna scaffalatura è un vero assassino.

mi ha fatto ricordare il suo libero con VS 2010

Answer 10

Davvero, si dovrebbe provare con una nuova, di prova, il sistema per valutarla. Un sacco di gente odia TFS e alcuni pensano che non sia adatto al loro modo di lavorare. Inoltre non è così gratuito quando devi iniziare ad acquistare le versioni migliori di VS per le funzionalità aggiuntive che ti interessano una volta che sei dipendente.

Ci sono recensioni sul web che non sono di MS Marketeers che dimostrano che TFS non è la cosa migliore da git. Il survey di Martin Fowler per uno è molto interessante (delle 54 risposte, nessuno pensava che fosse bello o addirittura buono). Forse i suoi lettori sono meno entusiasti degli strumenti di sviluppo del "lifecycle" rispetto alla maggior parte degli sviluppatori, ma poi, forse sono uguali a tutti noi. Sono disponibili recensioni simili - tra cui Forrester Research's piece (che ho letto: executive summary, SVN è "teh win" delle SCM standalone)

Quindi, solo perché TFS è ora incluso in VS non lo rende il migliore che ci sia.È necessario valutarlo correttamente prima della commutazione.

Answer 11

Sembra che ci siano molte persone che raccomandano il passaggio a TFS, mi piacerebbe andare dall'altra parte.

Sono passato dal lavoro con SVN a un lavoro precedente a TFS in un lavoro più recente. Lo riassumerei così:

L'integrazione è attraente e non c'è nient'altro che abbia tutte le parti integrate. Il compromesso è che ognuna di quelle parti individuali è una specie di schifo.

Più particolare:

Il sistema di controllo del codice sorgente, mentre tecnicamente molto buona sul server, ecc, è doloroso da usare. I file sono sempre contrassegnati come di sola lettura e devi verificarli esplicitamente per modificarli. Questo rende la tua vita orribile a meno che tu non stia usando l'integrazione dello studio visivo il 100% delle volte ... E se stai usando l'integrazione dello studio visivo, ricorda che memorizza lo stato SCC di tutti i tuoi file nel file CSPROJ, quindi sii preparato ad affrontare occasionalmente confusione e fallimento perché hai aggiunto il file a TFS, ma lo studio visivo non ha realizzato questo (o viceversa).

Il sistema di tracciamento dei bug ha una ricerca scarsa e limitata e l'interfaccia utente è difficile da utilizzare. Mi ricorda un sacco di vecchi moduli di database di accesso. Confronta questo con un buon tracker web-based pulito ed è notte e giorno.

Nel complesso, la maggior parte delle interfacce utente ha un'utilità davvero scarsa. Mentre puoi fare molte cose usando TFS, non sarà veloce, e dovrai fare clic su troppe caselle combinate!

Inoltre, TFS ha un'integrazione molto stretta con il tuo dominio. Se il 100% del tuo staff e tutte le tue macchine di build/test sono tutte nello stesso dominio, probabilmente questo va bene ... ma se non lo fai, questo ti farà soffrire.

Answer 12

Ho usato sia TFS 2010 e SVN (con Tortoise), si mescolano, MediaWiki, ecc

Anche TFS ti dà l'integrazione stile Source Safe con Visual Studio, è lì che finiscono le sottigliezze. SVN è molto più efficace nel controllo delle versioni, Mingle è uno strumento di collaborazione accecante e MediaWiki è un wiki molto migliore.

Se è necessario testare l'offerta principale di TFS come controllo del codice sorgente, quindi creare diversi progetti TFS, aggiungere alcune modifiche e provare a tornare a una versione precedente. Avrai bisogno di uno strumento prompt dei comandi e sarà perfetto se ti capita di ripristinare il progetto corretto dopo aver seguito le scadenti istruzioni online.

Answer 13

Dove lavoro, faccio migrare il gruppo a TFS da DOORS principalmente per requisiti, specifiche, ecc. Usano ancora Perforce come repository. Ho usato la maggior parte dei repository là fuori e ognuno ha le proprie stranezze.

Per rispondere alla tua domanda: qual è il problema che stai cercando di risolvere? Hai bisogno di una soluzione integrata per gestire i tuoi documenti, bug, controllo del codice sorgente? TFS fornisce la parte di integrazione in modo che ogni volta che si effettua il check-in del codice, è possibile taggarlo di nuovo su un bug, un requisito, una specifica. Questa è una grande caratteristica se la tua azienda utilizza molto processo. Mi sembra un piccolo negozio e non hai davvero bisogno di questo tipo di processo. Vorrei rimanere fedele a ciò che funziona finché non si cresce e le esigenze cambiano.

Answer 14

Se lo si utilizza solo per il controllo di versione, utilizzare SVN. Se hai soluzioni Linux/Java, continua con SVN. Se sei solo MS e hai voglia di usare elementi di lavoro per il requisito/bug tracking, ecc.(cosa che mi piace) consideri il passaggio a TFS ma ricorda che avrai bisogno di budget per CAL in modo che le persone possano accedere a queste informazioni. Se vuoi test durante la notte/build CI ricordati di budget per licenze VS aggiuntive per il tuo build server perché teambuild (msbuild) non può costruire un VDProjs, progetti Intel ecc.

anche ... TFS 'sembra'/' sembra "lottare con alcune cose davvero basilari, ad es come ignorare i file che non si desidera inserire nel repository e contrassegna frequentemente i file che sono stati modificati e che la differenza è identica.