Stampa

Effettua l'accesso o una nuova registrazione.
1 ora 1 giorno 1 settimana 1 mese Sempre
Inserisci il nome utente, la password e la durata della sessione.

[StM]

Io ho sempre usato semplicemente .cvsignore, e potrei usare .hgignore, per i file e le cartelle che non voglio gestire (infatti ho intere sottocartelle che ho escluso dal monitoraggio). La cosa migliore sarebbe che lo chiedesse almeno una volta, come mi succede con cvs e svn (anche usando i tortoise* relativi).

[Cherno]

Più che altro è un'assunzione sbagliata che se un file è sotto un albero, allora è da aggiungere al repository.

[StM]

Più che altro è un'assunzione sbagliata che se un file è sotto un albero, allora è da aggiungere al repository.

Per java è abbastanza logico che tutti i file che stanno nella cartella dei sorgenti finiscano nel repository (se non sono sorgenti correlati vuol dire che li metto in un altro progetto), e come ben sappiamo in java capita continuamente di aggiungere nuovi file. Ammetto che per altri linguaggi possano esserci molti motivi per non infilare nel repository qualsiasi cosa.

Comunque ho "risolto", per ora, facendo la ricerca di tutti i file da windows e facendo fare un hg add per tutti a TortoiseHG. La stranezza è che da questo sono stati esclusi i file .old, non so per colpa di chi (io non li ho messi in .hgignore).

Poi oggi mi sono rallegrato che per fare "la" commit iniziale di un progetto con qualche decina di migliaia di file in realtà ho dovuto fare una ventina di commit, per via del limite di lunghezza della linea di comando. Immagino sia il plugin ad essere ancora AMPIAMENTE migliorabile.

[Id]

Più che altro è un'assunzione sbagliata che se un file è sotto un albero, allora è da aggiungere al repository.

Per java è abbastanza logico che tutti i file che stanno nella cartella dei sorgenti finiscano nel repository (se non sono sorgenti correlati vuol dire che li metto in un altro progetto), e come ben sappiamo in java capita continuamente di aggiungere nuovi file. Ammetto che per altri linguaggi possano esserci molti motivi per non infilare nel repository qualsiasi cosa.

La penso come Cherno, e anch'io non trovo l'assunzione "tutti i file che stanno nella cartella dei sorgenti dovrebbero stare nel repository" COSI' ovvia, ad onor del vero.
E' ovvio - e lo e' in qsiasi linguaggio - solo se sei ordinato, e quindi non come me, che tutte le volte che faccio "svn status" mi vien fuori una lista immonda di cose che non sono uguali al server o che non ci sono proprio, e va bene che sia cosi'. E' che sono "file correlati" ma magari mi servono un giorno si' e due no per test o debug, o e' un backup "di riferimento" di qcosa che sto rifattorizzando e voglio tenere una copia della versione originale, o un mio livello di test "usa e getta" che sono un cialtrone e non c'ho voglia di cancellare perche' "sai mai", o...

[StM]

Io le cose di test le metto in progetti appositi in cui faccio tutte le porcherie che voglio, mentre le cose diverse tra client e server possono essere i file di configurazione (che bisogna tracciare in qualche modo se vengono aggiunti parametri, ma senza perdersi le personalizzazioni... argh!). E la rifattorizzazione sarebbe proprio il punto in cui il versioning (con branching efficente) serve, senza bisogno di tenere una copia di un sorgente

Comunque voglio specificare che non sto cercando di fare il saputello con Id, alla cui sapienza m'inchino e sempre m'inchinerò .

Probabilmente io ho passato quasi più tempo a studiare gli strumenti per programmare e a creare librerie e utilities (infatti sono il consulente fisso quando qualcosa non funziona ) che a programmare veramente o creare cose frontend, perciò bado molto alla forma dei "processi produttivi".

[Id]

Io le cose di test le metto in progetti appositi in cui faccio tutte le porcherie che voglio, mentre le cose diverse tra client e server possono essere i file di configurazione (che bisogna tracciare in qualche modo se vengono aggiunti parametri, ma senza perdersi le personalizzazioni... argh!). E la rifattorizzazione sarebbe proprio il punto in cui il versioning (con branching efficente) serve, senza bisogno di tenere una copia di un sorgente

Comunque voglio specificare che non sto cercando di fare il saputello con Id, alla cui sapienza m'inchino e sempre m'inchinerò .

Probabilmente io ho passato quasi più tempo a studiare gli strumenti per programmare e a creare librerie e utilities (infatti sono il consulente fisso quando qualcosa non funziona ) che a programmare veramente o creare cose frontend, perciò bado molto alla forma dei "processi produttivi".

Massi', dai, siam qui a parlare. Confrontare opinioni ed esperienze diverse e' l'intero senso della questione, nessuno pensa di darti del saputello

Per il resto, hai ragione: il refactoring e il porting sono le due cose per le quali generalmente versioning e branching efficienti sono capitali.
Poi dipende: se devo fare refactoring di una parte molto piccola - una giornata o due, non di piu', non sto a fare un branch apposta di tutto quanto il progetto, faccio prima a tenermi una copia del file in locale e bon.
E' che poi sono disordinato e non la cancello, che e' un mio difetto ma ho imparato a conviverci e quindi tipicamente me ne fotto e quel file rimane li'
Un'altra buona ragione e' che IMO il branching di SVN fa cagare e dove lavoro usiamo quello

Le cose di test mi piacerebbe farle, solo che sono sempre in produzione e non ho il tempo. "Fare o non fare, non c'e' provare"

[Cherno]

Io le cose di test le metto in progetti appositi in cui faccio tutte le porcherie che voglio, mentre le cose diverse tra client e server possono essere i file di configurazione (che bisogna tracciare in qualche modo se vengono aggiunti parametri, ma senza perdersi le personalizzazioni... argh!). E la rifattorizzazione sarebbe proprio il punto in cui il versioning (con branching efficente) serve, senza bisogno di tenere una copia di un sorgente

Comunque voglio specificare che non sto cercando di fare il saputello con Id, alla cui sapienza m'inchino e sempre m'inchinerò .

Probabilmente io ho passato quasi più tempo a studiare gli strumenti per programmare e a creare librerie e utilities (infatti sono il consulente fisso quando qualcosa non funziona ) che a programmare veramente o creare cose frontend, perciò bado molto alla forma dei "processi produttivi".

Ma no, non è il fatto di fare i saputelli però giustamente come dice Id dipende dalla situazione in cui ti trovi. Quindi preferisco che l'automatismo, nel caso specifico, non ci sia, perchè a volte è deleterio

[StM]

Devo aver detto una fesseria. Mercurial di default ti chiede se vuoi aggiungere i file nuovi creati, mi ero infognato con una regular expression . Ma continuo a non capire perché mi ignori gli .old e .bak senza possibilità di appello

[Id]

Devo aver detto una fesseria. Mercurial di default ti chiede se vuoi aggiungere i file nuovi creati, mi ero infognato con una regular expression . Ma continuo a non capire perché mi ignori gli .old e .bak senza possibilità di appello

Te lo chiede Mercurial, o il plugin per Eclipse? Cosi' per curiosita'.

Per gli .old e i .bak, che ti devo dire, sono vcs, son fatti cosi'. SVN a me ignora con regolarita' i file .a, dev'essere che ogni vcs c'ha un po' le sue antipatie

[StM]

Sia il plugin per Eclipse che TortoiseHG, e mi sa che "hg add" aggiunge automaticamente tutti i file non in .hgignore (adesso non ho il computer con il repository acceso, domani controllo). Poi da linea di comando si possono specificare varie opzioni, ad esempio ad "hg commit", quindi direi che c'è flessibilità.

A parte qualcosina qua e là, oltre a qualche baco nel plugin, l'unico grosso dubbio che mi rimane è il fattore umano

[Id]

Sia il plugin per Eclipse che TortoiseHG, e mi sa che "hg add" aggiunge automaticamente tutti i file non in .hgignore (adesso non ho il computer con il repository acceso, domani controllo). Poi da linea di comando si possono specificare varie opzioni, ad esempio ad "hg commit", quindi direi che c'è flessibilità.

A parte qualcosina qua e là, oltre a qualche baco nel plugin, l'unico grosso dubbio che mi rimane è il fattore umano

Il fattore umano... io l'ho risolto definitivamente minacciando i miei colleghi di "graffetta piegata sotto le unghie". Funziona abbastanza. 

[Ziggybee]

E' bello che il casinista che si è appena costituito sia quello che detta legge per tenere sotto controllo il fattore umano!

Cmq StM, questa dichiarazione è agghiacciante: "A parte qualcosina qua e là, oltre a qualche baco nel plugin, l'unico grosso dubbio che mi rimane è il fattore umano".

[StM]

Cosa ti agghiaccia di più delle 3 proposizioni?

[Ziggybee]

Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.

Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.

[Id]

E' bello che il casinista che si è appena costituito sia quello che detta legge per tenere sotto controllo il fattore umano!

Ci sono dei vantaggi nell'essere lead

Poi e' vero, io sono casinista in locale, lo ammetto serenamente - ma quando ho scritto "ho imparato a conviverci", intendo dire che so tenermi il disordine in locale mantenendo ordinato il repository del vcs, cosi' i miei colleghi non diventano scemi.