Uso del controllo di versione in un IDE [chiuso]

Uso quotidianamente Netbeans e Mercurial.

L'integrazione di Mercurial in Netbeans è buona, ma trovo che TortoiseHg sia molto più chiaro di quello che Netbeans può mostrare. Quindi, io uso entrambi gli strumenti:

In TortoiseHg , estraggo, spingo, eseguo il commit, unisci, aggiorno, tag, rollback, backout, import / export, ripristina, modifica .hgignore e hgrc file, guarda il grafico della cronologia , indovina copia / rinomina e biseca.

In Netbeans , traggo vantaggio dal diff interattivo (segni verdi / blu / rossi a sinistra dell'editor), inoltre traggo vantaggio dal fatto che i refactoring effettuati in Netbeans sono registrati in Mercurial . Ripristino file o parti di un file. A volte guardo il diff tra 2 revisioni, fianco a fianco. E a volte mostro le annotazioni (colpa).

Non discuterò perché faccio alcune azioni in uno strumento o in un altro. Non discuterò l'uso della CLI rispetto a una GUI. Questi sono gusti personali. Quello che volevo sottolineare è che nulla ti impedisce di utilizzare più strumenti per lavorare con Mercurial. Tutte le azioni che fai in entrambi gli strumenti (o con la CLI) saranno viste dagli altri. Ok, a volte devo dire a Netbeans di aggiornare chiedendo un hg% distatus, ma questo non è critico.

Notare che questo non è vero per Subversion + Netbeans. Quando stavo usando Subversion, ho avuto alcuni conflitti tra Netbeans e strumenti esterni quando lavoravo sulla stessa copia locale.

Utilizza il tuo IDE se ha un supporto discreto.

Guardalo in questo modo - la CLI ti dà lo stesso accesso ai dati grezzi, ma l'IDE / GUI può aggiungere molti modi convenienti per organizzare e visualizzare e gestire automaticamente (spostare / rinominare) quei dati. Nel mio, ad esempio (IntelliJ IDEA):

• Aggiungi automaticamente file
• Sfoglia tutta la cronologia
• Sfoglia la cronologia dei file
• Confronta con altra revisione
• Confronta con il ramo
• Fai clic con il tasto destro per visualizzare la cronologia linea per riga (annotazione / biasimo)
• Fai clic su un cambio di riga, quindi visualizza tutti i percorsi interessati in quella transazione (utile per vedere perché è stata apportata una modifica)
• Esecuzione di un movimento / rinominazione senza interruzioni quando si rinomino le classi o altri refactoring che influiscono sulla struttura dei file.

Per ricontrollare me stesso prima di eseguire un commit (sto usando Subversion ma se si sta usando un DVCS, sarebbe lo stesso prima di passare al repository centrale), la finestra di commit fornisce un comodo pulsante diff che Posso solo scorrere tutti i cambiamenti che ho fatto ancora una volta, per assicurarmi di non aver commesso errori stupidi.

D'altra parte , se dovessi mai spostare una posizione di repository, creare molte cartelle o estrarre alcuni file non voluti da una copia di lavoro a un'altra, uso spesso la riga di comando, come l'IDE VCS può intromettermi chiedendomi troppo spesso se voglio "aggiungere" il file, o eseguire un VCS Move / Copy quando in realtà non lo volevo.

Penso che dipenda molto dal tuo flusso di lavoro personale. Se l'IDE ti offre abbastanza funzionalità per il tuo VCS, perché dovresti passare alla CLI. Se questo non è il caso, cosa c'è di così male nella CLI.

Personalmente uso eclipse e mercurial. Ma non ho plugin in eclipse per hg. Dato che ho sempre almeno una shell aperta, è perfettamente normale con il mio flusso di lavoro per modificare qualche comando nella shell di volta in volta.

Per me funziona molto bene.

Dipende dalle tue esigenze e competenze con VCS e ovviamente dalla tua preferenza per una GUI o uno strumento di shell. Generalmente trovo gli strumenti IDE VCS dolorosi e troppo semplici per fare la maggior parte delle cose che voglio fare. E a meno che non creino alcuni widget GUI più flessibili, sembra che le GUI giocheranno per sempre con gli strumenti di shell molto più potenti disponibili.

Se hai un plugin che funziona bene, allora, perché non lo utilizzeresti? Se è possibile sfogliare facilmente le modifiche senza passare a un altro ambiente, si tratta di un notevole aumento della produttività.

Se non hai un plug-in, o non ti fornisce tutte le funzionalità di cui hai bisogno, allora, con tutti i mezzi, usa la CLI.

Uso ankhSVN con VisualStudio e funziona alla grande.

L'utilizzo dell'IDE è più semplice perché è a pochi clic da ciò che stai codificando. A volte è meglio usare una riga di comando perché hai più flessibilità e controllo.

Non c'è motivo di dover scegliere. Dovrebbero lavorare tutti insieme fuori dalla scatola. Uso Netbeans, Tortoise e command line (in linux solo Netbeans e shell).

Uso il mio IDE per codificare. (Visual Studio per esempio)

Uso un altro strumento per gestire i miei changeset. (TortsoieHg)

Uso un altro strumento per gestire compiti / bug / cose da fare. (TRAC / Redmine / ecc.)

Non li mescolo perché mi aiutano a passare da una mentalità diversa.

Quando codice, mi concentro sulla scrittura di soluzioni ai problemi. Disegno, penso, scrivo codice ecc. Quando penso di aver finito, esco dall'IDE.

Quindi sono in un modo diverso di pensare: rivedo il mio codice, usando lo strumento esterno. Per prima cosa lo avvio per verificare quali modifiche ho appena finito, poi ho letto tutto, vediamo se sembra giusto. Quindi commetto (o meno).

Dopodiché, do un'occhiata ad altri compiti da fare, e spesso è di nuovo in un altro strumento. Una volta deciso il prossimo compito e ho bisogno di progettare e scrivere il codice, torno all'IDE.

Senza questa separazione, mi concentrerei solo su una di quelle cose: codice, commit qualcosa, validazione / controllo delle attività. Uno di questi sarebbe fatto correttamente ma non gli altri. L'interruzione durante il passaggio degli strumenti consente di cambiare il contesto della mente e modificare gli obiettivi immediati.

Ma non sono sicuro che funzioni così per gli altri.

Ho sempre cercato di avere tutto nel mio IDE, ma ogni volta sentivo di fare troppe cose nello stesso tempo e di non farle molto bene. È come avere pagine web nella stessa schermata in cui è aperto l'IDE, non è possibile concentrarsi su entrambi.