SVN vsTeam Foundation Server [chiuso]

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

  •  08-06-2019
  •  | 
  •  

Domanda

Un paio di mesi fa la mia squadra è passata la nostra fonte di controllo, oltre a Apache Subversion da Visual SourceSafe, e non siamo stati più felici.

Di recente sono stato a guardare Team Foundation Server, e , almeno in superficie, sembra molto impressionante.C'è qualche grande integrazione con Visual Studio, e un sacco di grandi strumenti per gli amministratori di database, tester, project manager, ecc.

La differenza più evidente tra questi due prodotti è il prezzo.È difficile battere Apache Subversion (gratuito).Team Foundation Server è abbastanza costoso, in modo che le funzioni extra, sarebbe davvero a calci Subversion in pantaloni.

  • Qualcuno ha esperienza pratica con entrambi?
  • Come fanno a confrontare?
  • Team Foundation Server in realtà vale la pena la spesa?
È stato utile?

Soluzione

Ho aderito ad un progetto Open Source oltre a CodePlex, di recente.Usano TFS per il loro controllo del codice sorgente e devo dire che è assolutamente magnifico.Sono incredibilmente impressionato con esso, finora.Io sono un grande fan dell'IDE di integrazione e come è facile per ramo e tag di codice.Aggiunta di una soluzione di controllo del codice sorgente è qualcosa come due click, se hai già tutto configurato correttamente.

Ora.Vale la pena il cartellino del prezzo pesante?Io non la penso così.Il vantaggio di lavorare su progetti in CodePlex è che mi consente di ottenere l'esperienza con TFS che ho bisogno, nel caso in cui, sicuramente, da qualche parte più tardi.Se si vuole un buon IDE per l'integrazione del Controllo del codice Sorgente, andare afferrare VisualSVN pacchetto di integrazione.Si tratta di un molto, molto più economico di investimento per ottenere un sacco di le stesse caratteristiche (libera su computer non di dominio BTW).

Altri suggerimenti

Qui ci sono le più grandi differenze tra i due per me, e ho usato entrambi:

1) TFS è piuttosto strettamente connesso alla "Visual Studio modo" di fare sviluppo. Questo non per dire che il TFS è strettamente connesso alla VS IDE, significa che il TFS fatica a tenere il familiare "check-in"/"check out" paradigma di Visual SourceSafe, anche quando in realtà non si tratta di un modello più.Subversion concetto di "commit"/"update" è molto più realistico quando si dispone di sviluppatori che potrebbe trascorrere del tempo disconnesso dalla rete.TFS si aspetta che gli sviluppatori di essere sempre connesso al server.Questo è un grande segno meno.Personalmente trovo TFS per essere meno di trasparenza sulle modalità di organizzazione dei file sul server e sul vostro disco locale a causa della stretta integrazione con Visual Studio.Anche TFS più grandi sostenitori ammettere che la sua collegata check-in/check-out modello non è un'opzione interessante per gli sviluppatori che lavorano disconnesso.In un clima in cui le persone stanno iniziando a guardare DVCS come le opzioni di git e Mercurial su SVN, TFS del "check out" modello sembra un po ' come un dinosauro.

2) Costo. Quelli che dicono che il TFS non è caro e sono probabilmente molto piccoli negozi, o non sono in conformità con TFS termini di licenza.Hai bisogno di una Licenza di Accesso Client per maledettamente vicino a tutto ciò che si fa.Sei un manager che gestisce solo il bug?Avete bisogno di un ~$250 CAL (Ci sono 5 compreso, con un dettaglio TFS Licenza).Un utente business che vuole solo segnalare i loro problemi?UNA $250 CAL.Uno sviluppatore?$250 (a Meno che MSDN, nel qual caso è incluso).Il server?$500 (Incluso se si dispone di informazioni in lingua inglese).Naturalmente, qualcuno che vende una copia di TFS vi dirà che la gestione elementi di lavoro è gratuito per gli altri utenti, ma questi ulteriori utenti possono visualizzare solo gli elementi di lavoro che essi stessi a creare e non a tutto il team di elementi di lavoro, che non è troppo utile in un team-oriented, agile ambiente.Tutto questo aggiunge fino a quando si dispone di un'organizzazione di medie dimensioni, e diventa difficile giustificare, quando tanti best-of-breed prodotti come SVN e CruiseControl.net's incrementale costo è di $0.(In tutta onestà a TFS, però, sto ancora aspettando una davvero buona OSS issue tracker)

3) Struttura del progetto. In grandi squadre con un numero ristretto di progetti, TFS probabilmente funzionerà bene.Se sei un piccolo numero di episodi occasionali line-of-business app in-house, il TFS struttura può iniziare a diventare prepotente.Per una cosa, non è possibile definire una tassonomia dei progetti stessi-si può impostare "Zone" all'interno di un progetto, ma tutti i problemi e documenti sono tracciati insieme nel contesto di base di un "progetto".La creazione di nuovi "progetti" è spesso molto tempo, ed è eccessivo per piccoli sforzi.Naturalmente, SVN è niente del genere in quanto si concentra solo sul controllo del codice sorgente, ma se avete bisogno di una buona piccola flessibilità del progetto, SVN e un altro problema di strumento di monitoraggio potrebbe essere una scelta migliore.

La mia opinione, per quel che vale:

  • Per le grandi squadre con grandi, ben i progetti in bilancio, di Microsoft in un negozio dove gli sviluppatori lavorano quasi esclusivamente all'interno dell'IDE, il TFS è il vincitore.TFS vince anche quando è necessario centrale di applicare la politica con i vostri progetti.

  • Un certo numero di piccole squadre, con molte e varie, progetti di piccole dimensioni, o negozi dove il costo è un problema, o le squadre che hanno gli sviluppatori che lavorano scollegato dalla fonte di controllo, andare con SVN.

Sono sorpreso che qualcuno che ha usato Subversion in passato avrebbe anche avere una voglia/bisogno per TFS controllo del codice sorgente.

La mia esperienza con TFS (2005) è stato abbastanza orribile.Ho letto tutti i tipi di white & una guida su come strutturare correttamente la vostra fonte per le diverse esigenze di sviluppo.

La nostra semplice situazione, dove abbiamo un tronco con la linea principale di sviluppo, di integrazione e di ramo in cui siamo in grado di integrare le modifiche & deploy, e rilascia un ramo per tenere traccia delle versioni precedenti è molto comune e semplice, ma ci sono continuamente in esecuzione in problemi.

I miei problemi principali con TFS:

  • La fusione è un DOLORE in confronto a subversion.
  • Ci sono bug unfixed.Mi sono imbattuto in uno rinominare/fusione che è stato conosciuto per 2 anni e un fix non verrà mai rilasciato per il 2005.Abbiamo finito di spostare il ramo di una "rotta" cartella e noi lo ignoriamo ora.
  • Mettere in sola lettura serrature sul tuo file è attrito.Chi dice che ho bisogno di modificare il file batch e script di compilazione all'interno del TFS in modo che "check it out" per me?Subversion sa che i file modificati.Non ci sono readonly blocca lì.
  • Velocità.TFS è cane-lento su una rete WAN, ed è davvero utilizzabile solo se ho VPN in mio computer di lavoro, che rende il mio dev esperienza davvero lento in generale.
  • La mancanza di una buona linea di comando e l'integrazione con explorer.IDE integrazione è davvero bello per il giorno-per-giorno-l'Ultima, aggiunta di file, e il check-in, ma quando si ha bisogno di fare le cose in molti progetti, è bello avere dei buoni strumenti a vostra disposizione.E prima che qualcuno salti giù per la mia gola, sostenendo tf.exe funziona bene...non è davvero un cmd strumento linea.Per esempio, il check-in codice non dovrebbe comparire una finestra di dialogo modale.

...e la lista continua.Penso che anche con tutta la procedura di integrazione, non ci sono alternative gratuite che sono di gran lunga superiori.

Siamo un VS.NET negozio, e abbiamo implementato:

  1. Bugzilla per il problema di tracking
  2. Apache Subversion come un repository del codice sorgente di back-end
  3. VisualSVN Server per la gestione di SVN sul server
  4. TortoiseSVN (in Windows Explorer) e AhnkSVN o VisualSVN (in Visual Studio) sul client
  5. CruiseControl.NET per le generazioni automatiche

Costo:$0 Vantaggi:Impagabile

Se sei un piccolo team, o non si è pronti a comprare il che TFS processo, SVN e strumenti open source sono la strada da percorrere.

Come altri hanno sottolineato, il TFS ti dà molte più funzionalità di SVN non in forma di project management e così via.Avendo usato entrambi, e ha lavorato con grandi aziende nell'attuazione di TFS, ecco i miei due centesimi.

1) Se si utilizza TFS 2005, l'aggiornamento di TFS 2008.Mi ringrazierai.Ci sono un sacco di miglioramenti in TFS 2008, che la rendono praticabile.

2) Se si vive in Visual Studio e si desidera che l'IDE di integrazione, di andare con TFS.Ho usato SVN integrazione e quasi sempre cadere di nuovo all'utilizzo di TortoiseSVN.

3) Se ti piace l'idea dei conti integrato con l'Autenticazione di Windows, andare con TFS.La gestibilità dalla fine è bello.Ci possono essere i ganci per SVN - io non sono positive, ma se ti piace la GUI driven management, il TFS è difficile da battere.

4) Se avete bisogno di tenere traccia delle metriche o meglio, le modalità di attuazione di cose come criteri di check-in, vai con TFS.

5) Se ci sono persone che non implementare, se non è MSFT, andare con TFS.

6) Se si fanno più di .NET (lavoro Java, Eclipse, ecc) andare con SVN.Sì, ci sono prodotti molto buoni (come Teamprise) che funzionano bene con il TFS.Ma se altre lingue sono una piccola parte del tuo negozio, solo bastone con SVN.

Al di fuori di quella, SCM caratteristiche di entrambi sono più o meno equivalenti.Entrambi fanno la ramificazione e la fusione, entrambi fanno check-in atomici, che sia di supporto rinomina e si muove.Penso che per la gente che ha appena iniziato con la ramificazione e la fusione concetto, avendo i rami sono visibili in Esplora Controllo del codice Sorgente è bello.

TFS in realtà non è costoso ($1200 forse?).Rispetto a SVN è, forse.L'integrazione di reporting services e SharePoint è bello, ma di nuovo, se non la si utilizza, allora non importa.

Quello che vorrei dire è quello di scaricare la prova di 180 giorni di TFS e dare un andare.Eseguire una prova di side-by-side.Penso che sarete felici non importa in che modo si va.

Come Ubiguchi punti di TFS non è un controllo di versione del prodotto.Comprare TFS con l'intenzione di utilizzarla esclusivamente per il Controllo di Versione sarebbe chiaramente uno spreco di denaro.TFS è una suite integrata di strumenti per automatizzare tutti gli aspetti del Ciclo di vita dell'Applicazione di Gestione (e praticamente orientata a "L'Impresa".

Anche per Ben S post - non capisco il tuo commento sui blocchi.Le serrature non sono richiesti in TFS a tutti.Gli amministratori possono configurare TFS a lavorare come VSS (caratteristiche richieste da parte di alcuni "saggio" clienti") di "Get-Ultima Checkout" che ritengo, inoltre, fa un check-out di blocco.

Ma attraverso un uso "normale" del TFS un "check-out" si chiede all'utente per il tipo di blocco - e il valore di default dovrebbe essere "nessuno".Un utente PUÒ selezionare una check-out (o un check-in blocco) - ma non è obbligatorio.Se non si desidera che le serrature, non li uso.

TFS non traccia gli utenti che hanno il check-out sul server per vari sia per motivi di prestazioni (ottenere più recenti, più veloce) e la gestione del progetto (mi piace vedere cosa gli sviluppatori hanno i file estratti e per quanto tempo il loro check-out).

Io non sono davvero familiarità con SVN (non l'ho mai usato) -, quindi non posso commentare che "mergeing è peggio con TFS" - e non hanno colpito l'unione bug Ben indicato -, ma ho avuto un grande successo con la ramificazione e la fusione di utilizzo di TFS.

Un caso d'uso so TFS è ancora piuttosto debole è per gli utenti che sono regolarmente "non in linea".TFS è un Server "Prodotto" che presuppone che gli utenti sono connessi la maggior parte del tempo.L'esperienza offline migliorata nella versione 2008 (era triste nel 2005), ma ha ancora una lunga strada da percorrere.Se si dispone di sviluppatori che hanno bisogno (o voglia) spesso di essere disconnesso dalla rete per lunghi periodi di tempo, si sono probabilmente meglio con SVN.

Un'altra caratteristica da considerare per l'SVN tifosi che sono di utilizzo di TFS è il SVN Ponte un codeplex che permette agli utenti di utilizzare TortiseSVN per la connessione a TFS.Ho un buon amico e collega utilizza ampiamente e lo ama.

Anche il commento di una mancanza di linea di comando mi sorprende - strumenti a linea di comando sono ampie (anche se molti richiedono un separato download di TFS Strumenti di Potere

Ho il sospetto di Ben commenti sono basati su un eval della versione del 2005, che era chiaramente un "Microsoft V1.0" del prodotto.Il prodotto è attualmente in 2.1 con la Versione 3 in arrivo il prossimo futuro.

TFS è atroce.A questo punto ho il controllo di versione locale mediante SVN (w/ Live Mesh per il backup) perché ho molti problemi con TFS.Il problema principale è TFS utilizza i bolli di tempo per registrare se avete l'ultima versione, e memorizza i bolli di tempo sul server.È possibile eliminare la copia locale, ottenere la versione più recente da TFS, e si dice che tutti i file sono fino a data.E ' una stupida sistema che ti dà alcuna garanzia che la versione corretta del file.Questo comporta numerosi disturbi:

  • TFS deve essere informato quando un file viene modificato, quindi è necessario essere connessi al server in tutti i tempi.
  • TFS confondersi se si modificano i file al di fuori dell'IDE.Inoltre, esso consente di impostare tutti i file di sola lettura in NTFS.

Mentre TFS supporta la fusione, è davvero un checkin/checkout sistema.Se si modifica un file che spesso si è bloccato per altri sviluppatori.Ci sono modi intorno ad esso, ma il sistema è così contorto si corre sempre il problema.Per esempio, i nostri sviluppatori trovato che si può ottenere in giro tutti i file impostato in sola lettura in NTFS da check-out una soluzione completa, che consente di impostare un blocco esclusivo su tutti i file.Ho fatto questo un paio di volte, perché subversion ha la stessa sintassi per cassa, che non acquisisce un lock.

Infine il Team Explorer (il client) è un enorme 400 MB, richiede SharePoint server TFS e due giorni per installare.La sovversione un clic sul programma di installazione è di circa 30 MB per installare il server in meno di un minuto.TFS ha molte funzioni, ma la sua fondazione è così traballante non userai mai o cura di loro.TFS è costoso in termini di licenza, e nel tempo che gli sviluppatori di rifiuti ranting su stackoverflow, invece di scrivere il codice :P

La mia raccomandazione, Team System, non vale i soldi.Ho usato entrambi e dopo l'uso di Team System, ho provato a trovare una simile sostituzione.Fondamentalmente ciò che si sta pagando per l'integrazione e si potrebbe sostenere che la personalizzazione di supporto, ma sono stato in grado di creare un Team di sostituzione del Sistema con un po ' di tempo e di integrare gli strumenti insieme.

Di recente ho una domanda su quello che hanno fatto gli altri a venire con un Team di alternativa di Sistema.Ho anche l'elenco degli strumenti di sviluppo software che ho usato per creare la sostituzione.Spero che con questa risposta e la domanda che ho chiesto, è possibile trovare ciò che funziona per voi.

Io non sono un Team System hater, io non credo che vale la pena il denaro.Si tratta di un programma molto bello e se non ti dispiace pagare il prezzo, quindi con tutti i mezzi utilizzare.Era la ragione per cui ho creato la sostituzione mi è venuta.Volevo che la funzionalità di Team System fornito.

Qui è una versione open source di VisualSVN chiamato Ankhsvn.La sua molto meglio ora che linkiesta ha preso.

Se avete bisogno solo di controllo del codice sorgente, il TFS è eccessivo.Uno dei miei precedenti datori di lavoro ha TFS, VSS, e Sovversione nella loro impresa.Non abbiamo Active Directory o Exchange Server 2003 enterprise, quindi abbiamo finito per la creazione di separare gli utenti sul server TFS per permettere agli sviluppatori di utilizzare.Abbiamo avuto lo stesso tipo di problemi con la fusione che Ben Schierman citato, insieme ad altri il comportamento anomalo che ci ha spinto verso la Sovversione.

Se TFS è la scelta giusta per voi dipenderà in parte dal vostro budget, la dimensione del proprio team di sviluppo, e la quantità di tempo e di personale disponibili per la configurazione/manutenzione della soluzione.Se si desidera che il problema aggiuntivo di monitoraggio, di elemento di lavoro, di progetto e di statistiche capacità di TFS fornisce, potrebbe valere la pena cercare altre alternative.Prodotti come JIRA (da Atlassian Sistemi) o Trac ben si integrano con Subversion e fornire una sorta di svista di un progetto o di un programma di gestione potrebbe a un prezzo inferiore.

In un ambiente ideale, con Active Directory, Exchange Server 2003 o superiore, e personale dedicato per il repository, il TFS è più probabile che sia una buona scelta.

Ho usato sia al lavoro che a casa.Sono entrambi molto fresco nella loro propria destra.L'unica volta che mi sento di raccomandare di utilizzo di TFS, però, è se si prevede di utilizzare più funzioni rispetto al solo controllo del codice sorgente.Se avete bisogno solo di controllo del codice sorgente si può andare storto con SVN e questo è il motivo.

  1. VisualSVN Server Che è un completa SVN server con un bel plugin per gestire con.Esso consente di utilizzare l'autenticazione di windows destra tramite l'interfaccia utente.Facile.

  2. Tartaruga La sua tartaruga, ha detto basta.

  3. ankhsvn Si tratta di un grande SCC plugin.Per quelli che vogliono il full VS IDE integrazione l'ultima versione SCC plugin.Così si ottiene la piena integrazione per libero.

Al di sopra di set up è 100% gratuito e si ottiene attraverso tutto il necessario per il controllo del codice sorgente.

TFS non è solo di Controllo del codice Sorgente.Se si utilizza l'intero pacchetto di TFS offre, bug tracking, costruisce, relazioni, ecc quindi TFS è una scelta abbastanza solida (sicuramente meglio di quello Razionale).TFS, inoltre, ben si integra con Active Directory.

Anche se si sta parlando solo di SCM, quindi preferisco SubVersion.Non mi piace molto IDE integrazione.Mi piace anche SVN convenzione di Tronco/Tag/Rami struttura, e la relativa facilità di passaggio tra i rami.La fusione è sembrato più facile in TFS però.Tartaruga UI batte TFS mani di se, soprattutto per quanto riguarda l'aggiunta di un file repo.

Direi che è davvero dipende dalle tue esigenze.TFS è molto bello, io l'ho usato molto, ma molto, finalizzato a livello aziendale, se non avete bisogno di tutte le funzionalità potrebbe non essere necessario.Se hai bisogno di quelle caratteristiche (soprattutto la ramificazione, la scalabilità, gestione elementi di lavoro, etc.) sono vale ogni centesimo.Tenete a mente che il TFS include bug tracking, gestione elementi di lavoro e altre caratteristiche, oltre a controllo del codice sorgente.Se si dispone di più rami o se vi trovate in difficoltà contro una certa mancanza di funzionalità o di altri in Subversion, allora potrebbe essere una buona idea per passare.Ma il blocco è un buon motivo per passare probabilmente si dovrebbe evitare il costo e la produttività colpo di commutazione sistemi di controllo di origine.

Avendo usato entrambi a fondo, penso che a Cuneo è stato sul denaro, rilevando "TFS include bug tracking, gestione elementi di lavoro e altre caratteristiche, oltre a controllo del codice sorgente".

Tuttavia, posso onestamente dire che SVN e TFS sembrano abbastanza uguali in quanto a scalabilità, e se qualcosa SVN del controllo del codice sorgente è in vantaggio su TFS a causa della sua intrinseca semplicità.

Se si desidera elemento di lavoro e di tracciamento dei bug, a fianco di controllo del codice sorgente quindi andare per TFS o si va con SVN e alcuni altri, possibilmente gratis, strumenti come bugzilla.Mentre il TFS non integrare sia fonte di controllo e di elemento di lavoro di monitoraggio insieme sinceramente ritengo che MS dovrebbe avere dato via libera come una scusa per abusare di tanti sviluppatori con VSS nel corso degli anni.

Ho usato sia SVN e TFS.Vantaggio principale dell'utilizzo di TFS è la sua stretta integrazione con Visual Studio.Bug Tracking, le Attività di Monitoraggio saranno in un unico luogo.E i report generati per questi elementi saranno di aiuto del palo titolari di tenere informato lo stato del progetto.

Sto lavorando su un progetto con 5 persone e che di recente è passato da SVN a TFS.L'intero processo è stato un incubo.Abbiamo auto codice generato da XMLSpy, e TFS non riconosce i file modificati al di fuori di VS2008.Il TFS Strumenti di Potere in grado di analizzare il checkout e risolvere questo problema, ma è un dolore per ricordare l'uso di questi strumenti.Un altro problema che abbiamo costantemente a funzionare è il default strumento per unificare in TFS.È di gran lunga il peggiore strumento per unificare l'ho mai usato.Si potrebbe pensare che il TFS sarebbe in grado di gestire la soluzione di base che unisce, ma finora non è stato questo il caso.

La funzione integrata nell'interfaccia utente è molto utile, ma ha anche dei difetti.Se I checkout dal mio esplora soluzioni, a volte i file che sono stati aggiunti non vengono estratti.Se lo faccio da parte del Team di Controllo di Origine finestra funziona perfettamente.Perché è che?Aspetto con impazienza di TFS in VS2010 come ho sentito grandi cose su di esso, e SVN è ben lungi dall'essere perfetto, ma mi sarei aspettato alcune di queste funzioni un po ' più intuitivo.

Adam

TFS è grande per la gestione del progetto e di monitoraggio, tuttavia mi sento di controllo del codice sorgente non è buono come SVN.Qui sono i miei buoi con TFS:

Check-in/Check-out modello

Questo è un enorme con per TFS controllo del codice sorgente.Purtroppo, VS controlla automaticamente gli elementi per voi, anche se non vuoi.Sono stato in una situazione in cui qualcuno ha verificato alcuni file e poi andato in vacanza.Sono stato incaricato di ristrutturazione la struttura di directory, ma era impossibile, perché un gruppo di file sono stati estratti a quella persona.Non c'è modo nella GUI per annullare l'estrazione, il che significava che doveva essere fatto nella riga di comando.O ho dovuto capire come scrivere un potere script di shell per questo.

VS è tenuto a fare di tutto

A volte ho voglia di modificare un file di testo e il check-in.Questo richiede l'avvio di VS 2010, che è una bestia enorme, che per modificare un file e il check-in.Qualcosa che si prese un paio di secondi con SVN ora mi prende un minuto.

Come alcuni altri hanno sottolineato, i file sono contrassegnati leggere solo se non vengono estratti.Se renderlo modificabile e modifica al di fuori di VS, il TFS non riconoscere questo.Questo rende l'editing di qualcosa al di fuori della VS fastidioso.Questo significa, che si traducevano in VS, controllando i file, la modifica di un altro editor, il check-in in VS.

Alcune operazioni che sono state facili, in SVN sono ora un dolore

  • Forse non ho capito ancora, ma ho trovato che il rollback di un insieme di modifiche è stato molto noioso con TFS.

  • L'aggiunta di file al controllo del codice sorgente, che non sono parte di una soluzione, è un dolore enorme.Il TFS controllo del codice sorgente explorer mostra solo i file che sono in controllo del codice sorgente, non quelli che non sono (forse c'è un'impostazione da qualche parte per questo, non so).Con Tortoise SVN, si potrebbe semplicemente premere il Commit su una cartella e selezionare i file da aggiungere.

Attualmente sto conducendo lo sforzo di valutare TFS presso la mia società contro il Rational Suite, che è quello che abbiamo attualmente in uso.Finora TFS 2008 è pwning clearcase + clearquest.Il dev integrazione con l'ambiente è dove brilla davvero.

I miei 10 centesimi:

TFS2005 era uno scherzo - difficile da installare e ancora più difficile mantenere TFS2008 era stabile, più facile da installer, una facile manutenzione e automatizzato che si basa il lavoro.TFS2010 è EPICA!- installazione cane eassssyyy.La gestione è molto semplice;è tutta una gradevole interfaccia utente.L'integrazione con VS2008 non è così facile, poiché non è possibile creare progetti in vs2008 è necessario utilizzare vs2010 (che è stupido).TFS2010 permette anche di modificare il progetto sharepoint posizione invece di avere quei terribili sottocartelle di TFS2008.TFS2010 dispone anche di strumenti come un burndown chart che è veramente utile per la gestione del progetto.È come TFS2010 per l'intero team di produzione, compresi i clienti!Ancora costi troppo però :(

Anche prendere in considerazione che TFS richiede un SACCO di più horsepowers dal server hardware.E almeno uno di windows server licenze ofcourse.

Buone pratiche, come la nostra azienda ha seguito, è quello di utilizzare 2 server:front-end integrata (sharepoint), e una dedicata di sql server back-end (usiamo un'impresa cluster).TFS può essere installato su 1 macchina, ma non dovrebbe.

In confronto, il nostro svn server è installato su una virtual server linux con 256 mb di ram e 1 cpu, ed è ancora più grandezze più veloce quando si fa attività comuni come la checkout tutti.L'hardware virtuale è stato il più basso vshpere potrebbe assegnare!Il disco è veloce anche se (SAN).

Mi deve suggerire che il TFS richiede hardware dedicato per atleast $5000, mentre il server svn (su linux) può funzionare con qualsiasi hardware obsoleto per gli attuali sistemi operativi windows.

A mio parere dipende dalla situazione e l'ambiente in cui il progetto è fatto.Se si dispone di un semplice, piccolo progetto, quindi SVN è grande.Come già qualcuno ha scritto, VisualSVN si integra bene in Visual Studio s.t.non devi fare il checkin/checkout sul file system nativo.

TFS è grande per il controllo di versione, ma è ancora meglio se si ha realmente utilizzare tutte le sue capacità.Nei miei occhi diventa veramente la pena se si utilizza - per esempio - gli elementi di lavoro come il vostro repository integrato per la gestione del cliente segnalazioni di bug, nuove richieste di funzionalità e per il monitoraggio dello stato di avanzamento del progetto la gestione di compiti e il secondo rango di tempo, tempo e tempo rimanente indicazioni.
Ciò che è davvero interessante è quello di utilizzare la funzione di associare gli elementi di lavoro, con codice sorgente archiviazioni.Vedere qui per ulteriori informazioni in merito.

Siamo un piccolo team nel processo di migrazione da SVN a TFS2010.Il nostro più grande motivo per farlo è l'integrazione in Visual Studio e il WebAccess per bugtracking, che è ora parte del TFS.

@Adam:Speriamo di avere una migliore esperienza.Non si può dire ancora...

Ho usato SVN negli ultimi 3 anni (provenienti da VSS precedente) e, recentemente, ha dovuto passare per TFS2010.La sensazione generale è che è buggier di SVN e fatta eccezione per la bella integrazione con le attività/bug non vedo come avere un vantaggio contro SVN.La velocità sembra anche essere un po ' più lento con SVN.

Se dovessi scegliere un sourcecontrol ora vorrei ancora andare con SVN.

Per quanto riguarda gli strumenti:- AnkhSVN Visual Studio Plugin è buono come il TFS controllo del codice sorgente - Tartaruga è molto meglio di TFS controparte

TFS è grande, se non hai bisogno di non sviluppatori, per arrivare al pm di roba.

Il nostro helpdesk deve essere coinvolto nel processo, e solo che non era il taglio.

Anche la gestione delle build in tfs 2005 almeno, è attrotious, e non è in grado di costruire vs 2008 slns.Non mi piace che la mia fonte di controllo, scelta, influenza le mie scelte di distribuzione, questo è perché la mia squadra non è un svn negozio.

Se solo basato sul controllo del codice sorgente, mi piacerebbe andare con SVN.Il AnkhSVN add-in per Visual Studio è stata notevolmente migliorata nella sua nuova versione.Inoltre, è possibile ottenere il codice sorgente per l'SVN e la documentazione è grande!Hanno cambiato alcune arcane cose nel 2010 TFS Controllo del codice Sorgente, e senza il codice sorgente può essere molto scoraggiante per risolvere i problemi.Inoltre, dipende dal fatto che i team MSDN per pompare fuori il doc e lo fanno con i propri tempi e alla loro profondità.

Detto questo, TFS, ovviamente, offre molto di più di controllo del codice sorgente.Si tratta di un ALM strumento.La combinazione con gli elementi di lavoro, di reporting, di generazioni automatiche, gated check-in, automazione dei test, etc.può fornire alcune molto ricco di valore che si può ottenere solo con la connessione di diversi strumenti con SVN.E, naturalmente, di avere la sorgente per l'SVN non è un modo.Ho ottenuto in scenari con SVN, dove avrebbe ancora preso settimane per totalmente a capire cosa stava succedendo.

Quindi, vi consiglio di guardare da un'ALM prospettiva e vedere se la vostra azienda sta andando a utilizzare tutti i TFS caratteristiche o sta andando con un best-of-breed strategia (ad es.JIRA).

TFS da un miglio.

Ho inavvertitamente causare troppi problemi per me con SVNs file-based approach.Controllo del codice sorgente problemi che ho sperimentato:TFS – 0 problemi oltre 2 anni SVN – perso il conto...

Sì, lo so il prezzo di TFS fattori per la maggior parte delle aziende che è una vergogna.MS potrebbe avere molto di più quote di mercato (e di profitto) se avessero un ragionevole modello di pricing.

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