Quali vantaggi ha TFS rispetto a Tortoise SVN in questo scenario?

Entrambi faranno ciò di cui hai bisogno. Al mio ultimo lavoro, abbiamo iniziato con SVN e trasferito a TFS in seguito. Il nostro team era composto da 8 sviluppatori e 3 controlli di qualità.

TFS era bello b / c che aveva costruito nel supporto VS, integrato nel monitoraggio dei ticket, e si potevano bloccare i file. Abbiamo anche utilizzato SharePoint per tenere traccia di tutti i documenti e le note di riunione per ogni progetto. Era molto bello e integrato ... ma era anche dannatamente costoso.

SVN andava bene per i nostri scopi. Quello con wiki e Jira e siamo stati bravi. L'unico motivo per cui siamo cambiati è stato il management di b / c, abbiamo deciso che dovevamo essere un Microsoft Shop.

Direi che è uno strumento utile se puoi giustificare costi e spese generali. Altrimenti, non puoi sbagliare con SVN.

Se vuoi l'offerta migliore per gli sviluppatori, diventa moderna.

Uso quotidianamente svn e mercurial.

• svn: perché llvm / clang lo usa e sto seguendo il progetto
• mercurial: at work;)

Non posso dire quanto posso odiare svn, davvero ... una volta che hai assaggiato il sistema di controllo della versione distribuito e (in particolare) i commit locali, tornare indietro è come uno schiaffo in faccia.

Non riesco a confrontare mercurial vs git, perché non ho usato git.

Uso Tortoise per progetti personali a casa e TFS al lavoro. Tortoise SVN è bello, ma devo dire che TFS è piuttosto idiota. L'integrazione IDE lo rende l'opzione migliore quando si ha un gruppo di sviluppatori sul progetto con una quantità mista di esperienza con il controllo del codice sorgente. Dico questo perché, credimi, vuoi che la curva di apprendimento sia il più superficiale possibile. Con un investimento come questo, tutto ciò che può richiedere è un link debole che cancella accidentalmente il progetto dal server, o rovina la tua ramificazione ovunque, e non vuoi che ciò accada. Detto questo, amo Tortoise per uso personale o con un team fidato, TFS ha semplicemente una GUI migliore.

Ciò che descrivi sembra perfettamente realizzabile con SVN. Non so molto di TFS, quindi non posso fare commenti su quella parte. Ma penso che altre due domande importanti siano: il management si preoccupa di cosa usi e qual è il software standard da utilizzare per il controllo della versione nella tua azienda? Dall'altra parte cosa gli sviluppatori vorrebbe usare? Conoscono TFS o SVN?

Secondo me è meglio avere uno strumento leggermente meno avanzato che gli sviluppatori preferiscono e utilizzare piuttosto che uno strumento di fantasia che nessuno usa. Qui la maggior parte del lavoro viene ancora eseguita in SourceSafe finché le persone ne sono felici, non vedo alcun problema. (come sidenote stiamo mettendo le persone entusiaste su SVN qui :))

Uso quotidianamente TFS, SVN e Mercurial. Al momento, TFS viene utilizzato solo per il controllo del codice sorgente / bug tracking.

Mercurial ha completamente cambiato il modo in cui utilizzo il controllo del codice sorgente. Ogni volta che apporto una modifica posso impegnarmi. Supponiamo di dover implementare una funzionalità che richiede la modifica di tre metodi e l'aggiunta di due. Il mio flusso di lavoro è così:

• Cambia metodo 1;
• Commit;
• Cambia metodo 2;
• Commit;
• Cambia metodo 3;
• Commit;
• Aggiungi metodo 4;
• Commit;
• Aggiungi il metodo 5;
• Commit;
• Push.

In SVN, va così:

• Cambia metodo 1;
• Cambia metodo 2;
• Cambia metodo 3;
• Aggiungi metodo 4;
• Aggiungi il metodo 5;
• Commit.

Se faccio un errore a metà tra la modifica del metodo 3 e l'aggiunta del metodo 4, sono bloccato: non ho modo di ripristinare altro che fare una sorta di diffusione manuale tra l'ultimo commit e il mio stato corrente del codice. Con Mercurial, è facile vedere cosa ho fatto di sbagliato in quanto ho un commit più recente. Non riesco a seguire il flusso di lavoro Mercurial con SVN perché se lo faccio, interrompo la compilazione. Mercurial si impegna localmente, quindi non è un problema.

Per quanto riguarda TFS, lo detesto. È indietro, lento, gonfio e brutto. Può fare grandi cose con l'integrazione continua, ma puramente come sistema di controllo sorgente succhia .

In breve:

• Mercurial cambierà la tua vita in meglio.
• SVN è ancora una buona opzione, specialmente se la stai già utilizzando.
• TFS cercherà di ucciderti mentre dormi.

Non so molto di Tortoise SVN, ma posso dirti che la fusione in TFS è piuttosto semplice e che la scaffalatura funziona sicuramente! Uso le scaffalature ogni volta che devo partire per il giorno e non sono in grado di effettuare il check-in. La Continuous Integration (CI) è anche abbastanza decente. Inoltre ci sono un sacco di altre funzionalità per un'impresa più grande.

Se hai intenzione di sviluppare una soluzione non Windows, esegui il dump.

Ha problemi con le soluzioni basate su Linux esistenti (e varianti: eCos, uClinux, ecc.)

1. Linux supporta come caratteri nei nomi dei file (come "|", ":", ecc.) che NON sono supportati da Windows. Il server TFS rifiuta questi file quando tenta di aggiungerli.
2. Invece di confrontare il file locale con il file di repository per determinare se un file è "cambiato" (come la maggior parte degli altri VCS), modifica l'autorizzazione del file sul lato client per indicare agli strumenti client quali file effettuare il check-in. File le autorizzazioni in Linux significano cose diverse da quelle di Windows e questo fa male alle soluzioni Linux.
3. TFS interagisce abbastanza bene con gli strumenti di sviluppo di Microsoft ma funziona male con i plugin, è assente per la maggior parte degli strumenti e in definitiva richiede uno strumento client Windows per interagire con TFS, che non è disponibile in molti casi.