2009-01-10 24 views
21

Sto sviluppando un'applicazione per Mac come una piccola squadra (io + un'altra persona) sforzo. Siamo situati in diverse città e abbiamo iniziato a vedere la necessità di una solida gestione del controllo delle fonti.Quale sistema SCM per Xcode?

Nessuno di noi ha esperienza con questo, ed entrambi siamo relativamente nuovi a Cocoa/Obj-C/Xcode (ma hanno conoscenza di C).

Qualcuno ha qualche consiglio su quale sistema SCM scegliere? Capisco che molte persone stanno usando Subversion, che è supportato anche in Xcode 3.1. Qualcuno ha esperienza con l'utilizzo di Subversion tramite Xcode? O è un'opzione migliore per scegliere un'alternativa GUI stand alone, come le versioni?

Grato per qualsiasi input su questo.

Gregor Tomasevic, Svezia

Aggiornamento/esperienze personali: Dato questo post, abbiamo provato Versioni e Cornerstone (che sono entrambi SVN GUI-clienti), così come Xcodes supporto incorporato per SVN . Non siamo rimasti particolarmente soddisfatti con Versions, che sembrava avere qualche problema con il commit di file/file non convertiti. Il supporto SVN incorporato in Xcode funziona abbastanza bene, anche se probabilmente ha delle limitazioni che non abbiamo ancora incontrato. La pietra angolare è semplice da usare e potente e non sembra soffrire dei problemi che abbiamo incontrato con le versioni.

Finora, abbiamo appena provato a commettere, aggiornare il repository, controllare le versioni più recenti/precedenti dei nostri file e abbiamo lavorato con il confronto dei file. Potrebbe essere un gioco di palla completamente diverso una volta che inizierai a lavorare intensamente con la ramificazione, un'area a cui abbiamo detto che entrambi questi client GUI potrebbero avere dei punti deboli.

Per quello che vale (e con solo giorni di valutazione) Cornerstone sembra essere un'alternativa un po 'migliore, anche se per SCM più semplice, Xcode funziona bene anche.

Grazie per tutti i commenti.

risposta

6

Non si può veramente sbagliare con l'uso di Subversion.

Se, come me, non ti piace troppo l'integrazione SVN di Xcode, puoi sempre scegliere di utilizzare gli strumenti da riga di comando o una delle varie applicazioni della GUI come Versioni, CornerStone o SvnX. Molti di questi strumenti funzionano abbastanza bene, quindi non sei necessariamente legato allo strumento con cui inizi.

Io personalmente faccio la maggior parte del mio lavoro con Versioni e uso gli strumenti da riga di comando con le stesse copie di lavoro ogni tanto.

Se sei a tuo agio a lavorare con gli strumenti da riga di comando esclusivamente fino a quando qualcuno non crea una buona applicazione GUI attorno ad esso, git è anche un'opzione abbastanza valida.

divulgazione: io sono una delle persone che lavorano su versioni, quindi potrei essere un po 'di parte;)

+1

Si usano le versioni? C'è una sorpresa! ;-) – Abizern

+9

Un paradigma di per sé non costituisce un grande flusso di lavoro. Il semplice fatto che sia possibile scegliere tra client della riga di comando, Cornerstone, Versions, SvnX, ecc., Conferisce a SVN un vantaggio molto tangibile. –

+0

@foljs: così gli ingegneri del software del mondo reale hanno un secolo di esperienza in più con SCM centralizzato? ;-) –

1

Se avete intenzione di sovversione, ho sentito cose positive dette su Springloops. Io codice insieme ad alcuni amici anche in modo simile e usiamo Github. Git è un'esperienza meravigliosa. Non utilizzo alcuna GUI perché è molto più efficiente con un prompt della shell. Ma naturalmente, sarei felice se Xcode avesse il supporto per i repository Git.

6

Il supporto Subversion di Xcode è piuttosto buono. Il 90% delle attività SVN che eseguo sono facilmente realizzabili da Xcode. Per le altre cose ho appena acceso il terminale.

ci sono un paio di cose nella loro attuazione client SVN che sono fastidiosi:

  • Il codice che controlla per vedere quali file locali sono stati modificati sembra colare su un timer di fondo, e la sua bella latente. A volte occorrono 5 minuti affinché Xcode mostri un file come modificato. La stessa cosa è ancora più esagerata con le modifiche remote w/r/t.
  • A volte quando si rinomina o si elimina un file che non è sotto il controllo del codice sorgente, viene visualizzata una finestra di dialogo che richiede "Desidera [rinominare/eliminare] questo file anche in SVN?" E le opzioni sono "Sì" o "Annulla". Scegli Sì per disperazione solo per essere presentato con un errore SVN ben meritato.

Nel complesso, lo consiglio.

20

Xcode supporta solo Subversion, Perforce e CVS. Tuttavia, ci sono anche sistemi di controllo della versione distribuiti, come Mercurial, Bazaar e Git. Questi non hanno GUI Mac-native, ma dovresti comunque considerarli. Personalmente, adoro gestire i miei progetti nei repository Mercurial.

[Aggiunto il 2011-03-10] Xcode 4 aggiunge il supporto per Git. Molti di noi hanno presentato richieste di supporto Mercurial; dovresti, anche tu, se lo vuoi

+2

ho sentito (ma non ancora provato) di GitX (http://gitx.frim.nl/) per una GUI Git. – mouviciel

+3

C'è anche Murky (https://bitbucket.org/snej/murky/) per Mercurial. –

+0

GitX è davvero buono e anche Murky è decente. Entrambi hanno le proprie prese sull'interfaccia utente, ma sono buoni strumenti, entrambi. – RyanWilcox

3

Subversion è la soluzione di controllo del codice sorgente OS X tradizionale, in Leopard è supportato in Xcode e OS X, per non parlare delle applicazioni GUI di terze parti (alcune delle quali sembrano molto slick). Nonostante tutto ciò, molti sviluppatori indipendenti di OS X sono passati a Git negli ultimi due anni. Come singolo sviluppatore posso dirti che Git si è rivelata un'ottima soluzione per me, e insieme a Github rappresenta un'ottima soluzione per un piccolo sforzo di squadra.

5

Caveat: Se avete semplicemente dici XCode per aggiungere un progetto in un repository dandogli la directory di livello superiore, si aggiungerà la cartella di generazione al repository, che naturalmente è una cosa terribile da fare.

Per aggirare questo devi spostare la cartella di costruzione in un'altra posizione in modo che XCode non tenti di importarlo, o aggiungere manualmente le cartelle discrete di un progetto uno per uno.

+0

Basta aggiungere la directory di livello superiore, quindi rimuovere la directory di build dal repository. È fastidioso, ma piuttosto facile da aggirare. – kubi

+1

Creo il progetto, lo faccio completamente pulito (rimuovi le directory di creazione), quindi eseguo il primo commit (aggiunta o qualsiasi altra cosa). Più tardi, quando viene creata la directory di costruzione, svn la ignora (mette un? Accanto ad essa) perché non l'ho mai aggiunta. –

0

Mercurial (come Git) viene "distribuito" e forse considerato come più moderno e up-e- arrivando da svn (ma meno stabilito). Se si vuole auto-check-in utilizzando mercuriale, è possibile aggiungere la riga:

hg commit -m "Xcode commit automatico"

come parte di un "Run Script" fase della costruzione XCode, come si trova in : Progetto> Nuovo Fase di costruzione> Nuovo Esegui script di build Fase

+6

Ooh, cattivo consiglio. Controllando ogni volta che il codice viene compilato è puzzolente; i check-in saranno limitati a singoli file (il raggruppamento dei file fornisce un suggerimento naturale sul significato del check-in), oltre al quale non vale la pena tenere in considerazione tutti i cambiamenti di codice che costruisce! Infine, ci si ritroverà con migliaia di check-in tutti con la stessa voce di registro, rendendo difficile trovare un cambiamento specifico lungo la strada. -1 nello spirito, anche se non mi sento abbastanza meschino per in realtà di downvotare - dopotutto hai raccomandato Hg. –

+0

Sono d'accordo sul fatto che sia una storia molto complicata, ma se per i piccoli progetti trovo più comodo farlo, assicurandomi almeno che possa tornare indietro quando necessario. Se vuoi davvero qualcosa di più pulito, ovviamente, sono i check-in manuali e/oi punti di diramazione denominati. – Greg

14

C'è una bella interfaccia grafica per Mercurial su Mac chiamato MacHG: http://jasonfharris.com/machg/

e 'gratuito e molto bello IMHO.

+3

Il panorama è spostato da quando questa domanda è stata postata per la prima volta, e mentre è bello che Apple sta mettendo più impegno nell'integrazione SCM con Xcode4, MacHG batte ancora ogni altro client SCM visivo che ho visto fino ad oggi - Xcode4 Dev Preview 2 incluse-mani giù. Quindi, mentre Gregor probabilmente si sente ormai trincerato con svn, ogni nuovo venuto dovrebbe provare la combinazione di Mercurial (cioè, hg) + MacHg + http://bitbucket.org (se hai bisogno di un equivalente a github). – clozach

+0

Seconded! Ho anche sperimentato il controllo della versione distribuita e recentemente ho scoperto MacHG. È così bello, mi manca quando lavoro su Windows! (E questo è anche con TortoiseHG.) –

2

Se sei interessato all'utilizzo di Mercurial su OS X, prova SourceTree, non è gratuito ma ha un prezzo competitivo e ha un aspetto Mac OS molto raffinato. L'ho utilizzato per progetti personali negli ultimi mesi, a fasi alterne, trovandolo intuitivo e ragionevolmente robusto.

È disponibile tramite Mac App Store e supporta Git e Mercurial. Hanno un sito web al http://www.sourcetreeapp.com/ con ulteriori informazioni.

+1

È stato gratuito da quando Atlassian lo ha comprato. (Hanno menzionato un paio di volte che questo è "per un tempo limitato", ma non ho visto alcuna menzione di una data specifica in cui quel tempo si esaurirà.) –

Problemi correlati