TW: differenze

[r.bianco]

Mi capita di dover eseguire delle operazioni (chekin) per tutti, o quasi, gli elementi nella lista delle differenze tra locale e server. Così come è adesso sono costretto a portare uno ad uno tutti gli elementi nella sezione sottostante: quando gli elementi sono tanti diventa molto, molto scomodo.

Propongo di poter selezionare tutti gli elementi e portarli in blocco nella sezione sottostante.

[C.Zecca]

Aggiungo un'ulteriore questione rispetto a diff e check-in.
TW permette di richiedere le differenze tra copia locale solo su alcuni elementi: videate complete, metodi, comman set etc.
Ad esempio è possibile richiedere le differenze tra il metodo
MioPannello.OnDynamicProperties() locale e la versione presente sul master.

In genere se appare nel menù contestuale il 'Mostra differenze' (ed è stata eseguita qualche modifica e relativo check-out) appare anche il 'Check-in'.

Ecco, la cosa mi ha fregato un tot di volte oggi >:/ fino a darmi lo stimolo per questa richiesta, sgrunt.
Se si esegue il check-in di un metodo viene eseguito il check-in dell'intera videta cui esso appartiene (il commento preparato per il metodo non va ovviamente bene come descrizioe per il check-in di tutte le parti!).

Se non si può isolare il check-in al solo metodo suggerirei di eliminarlo dal menù contestuale sui metodi, per esporre (correttamente e coerentemente) che quel comando si esegue su tutta la videata e che non è possibile eseguirlo specificatamente per un metodo.

[r.bianco]

Mi pare ragionevole

[C.Zecca]

Considerato che Team Works NON supporta sviluppo multi branch, il poter segmentare i check-in per unità piccole (ad esempio il metodo, il pannello...) diventa ancora più importante.
In questi giorni un sacco di lavoro extra per via di rilasci su correzioni: il codice nuovo (talvolta incompleto) deve essere reso inerte in qualche modo (eliminato, commentato, messo in if () a espressione falsa etc.) anche se relativo ad altri metodi della videata e poi ripristinato.
L'inconguenza che il diff è disponibile mentre non il check-in (parlo dei metodi) quando altrove non sono disponibili entrambi può indurre in errore.

[C.Zecca]

Su metodi che iniziano ad avere qualche complessità, il diff di TW risulta spesso di disagevole lettura e quindi ostico in comprensione.
In casi estremi come procedo?

1 - Seleziono il metodo mioMetodo() nella vecchia versione
2 - Modifica - Copia come testo
3 - Salvo in contenuto in mioMetodo_old.html
4 - Carico mioMetodo_old.html in un browser
5 - Seleziono tutto il testo, Copia
6 - Creo file di testo mioMetodo_old.txt, Incolla

Ripeto i passi 1 - 6 per la versione corrente, fino a creare mioMetodo.txt
Con uno strumento di verifica delle differenze tra file di testo verifico le differenze tra mioMetodo_old.txt e mioMetodo.txt.
Ecco il risultato



Sarebbe molto gradito che questa semplice procedura fosse implementata nella IDE In.De e venisse offerta come opzione di diff quando gli oggetti in confronto sono metodi (funzioni e procedure)

[g.lanzi]

Temo che ci sia un po' di confusione su TW.

Solitamente un software di versioning lavora un file alla volta. Si fa il check-out, il check-in o il merge di uno o più file per volta.
Ogni form è un file a sé, ma TW permette di poter gestire il lock, il check-out e il check-in di oggetti più piccoli, arrivando alla granularità della procedura.

La differenza notata nel check-in da c.zecca è derivante dal fatto che In.de effettua il check-in di tutti i lock presi per lo stesso motivo. Faccio un esempio.

Lavoro sulla FORM_A e sulla PROC_A all'interno della form. Se prendo il lock sulla videata perché comincio ad editarla, non sarà necessario prendere il lock sulla procedura perché l'utente possiede già il lock su tutta la form. Facendo check-in sulla procedura si sta in effetti committando la form.

Se invece comincio a lavorare sulla PROC_A allora prendo il lock sulla procedura, e se poi modifico qualche altra parte della form avrò altri lock su quelle parti. Quando faccio check-in della PROC_A sto committando solo quel lock.

È da notare un'altra cosa, che quando l'utente modifica un oggetto In.de prende il lock su tutti gli oggetti che devono essere modificati di conseguenza. Tutti questi lock sono lock distinti, ma verranno sempre committati insieme, perché facendo diversamente il progetto su TW non sarebbe integro, in quanto comprenderebbe solo una parte della modifica.

Per conoscere la forma e lo stato dei check-in non bisogna basarsi sulla visibiltà del comando check-in, ma sulla videata dei lock, disponibile tramite la voce di menu TeamWorks -> mostra lock. L'ultimo campo è il GUID identificativo della modifica che ha causato i lock. Tutti quelli con lo stesso GUID verranno inseriti insieme sul server, anche eseguendo il check-in esplicito di uno solo di essi. La stessa cosa accade per le modifiche innestate e correlate.

TW inoltre permette il branch dei progetti. Da questo punto di vista la guida all'uso spiega qualcosa.

Insomma, si può segmentare i check-in in unità ben più piccole del normale file gestito da SaveVersioN o da SourceOff, ma TW impedisce di effettuare commit che corrompano l'integrità del progetto caricando modifiche parziali.
Per agire direttamente su come vengono presi i lock da In.de è sempre possibile usare il comando check-out per informare l'ambiente di volere un lock specifico per un determinato oggetto.

M'interessa anche capire l'attrito provato nella lettura del diff di TW, che mi sembra molto migliore di un diff di puro testo. Mi puoi spiegare meglio quali sono i punti deboli della schermata di differenze, che ne rendono ostico l'utilizzo nel tuo caso?

Il caso di r.bianco, invece, è particolare e andrebbe visto in assistenza. Non ci risulta questo comportamento e mi piacerebbe vederlo per capirne la causa.

[r.bianco]

Ricevuto =)

[C.Zecca]

M'interessa anche capire l'attrito provato nella lettura del diff di TW, che mi sembra molto migliore di un diff di puro testo. Mi puoi spiegare meglio quali sono i punti deboli della schermata di differenze, che ne rendono ostico l'utilizzo nel tuo caso?

Fondamentalmente che ciò che appare nella schermata di confronto NON è ciò che lo sviluppatore vede nei sorgenti.
Stamani ho dovuto usare il diff con una certa frequenza avendo su un altro .IDP le modifiche originali: dovevo controllare che tutte esse fossero riportate nel .IDP "principale" volendo evitare di avere i due file entrambi aperti e di commutare continuamente tra corrispondenti punti dei sorgenti dei due .IDP.
In altre parole avevo la necessità di "leggere" il sorgente e per fare questo mi sono dovuto ricostruire mentalmente il testo sorgente per "capire" le modifiche partendo dal formato diff riportato attualmente.
Nel confronto mi sono accorto, ad esempio - correggetemi se ho capito male - che quanto appare nel testo sorgente

Code: Select all

if ( condA and condB )

nel grafo viene sviluppato all'incirca come

Code: Select all

if ( [Parametri Videata TalDeiTali] condA [ - ab cd ef ] )
    if ( [Parametri Videata TalDeiTali] condB )
        Nuovo Statement
        ...
}

con varie informazioni tecniche che non appaiono nel sorgente e che lo rendono "lontano" da esso.
Allora ci deve essere un'attività di reverse engineering nella capa dell'umano ;) per ricostruire i sorgenti che diventa piuttosto faticosa, specie se le modifiche hanno qualche giorno.
Aggiungo che come utilizzatore della In.De abbastanza recente leggo e ragiono in termini di sorgenti più facilmente che in termi di grafo.
In un certo senso quando le cose non sono banali e ho la necessità di un "checksum" a livello di testo che NON ci siano effettivamente differenze, parto con la procedura indicata sopra (non frequentemente perché richiede tempo).
Se i sorgenti in formato di testo sono identici sono deterministicamente certo dell'assenza di differenze.

Può essere che la scarsa attitudine a pensare in termini di grafo possa spiegare anche altre incomprensioni.
Cercherò di recuperare le info sulla gestione a rami di sviluppo paralleli (branch) dall'ultima versione del manuale e di studiarmele, in quella che ho cartacea, se ricordo bene, non avevo trovato che degli accenni. Devo controllare.
Appena possibile mi studio il resto della risposta, merita attenzione.
Grazie.

[C.Zecca]

Temo che ci sia un po' di confusione su TW.
Lavoro sulla FORM_A e sulla PROC_A all'interno della form. Se prendo il lock sulla videata perché comincio ad editarla, non sarà necessario prendere il lock sulla procedura perché l'utente possiede già il lock su tutta la form. Facendo check-in sulla procedura si sta in effetti committando la form.

Se invece comincio a lavorare sulla PROC_A allora prendo il lock sulla procedura, e se poi modifico qualche altra parte della form avrò altri lock su quelle parti. Quando faccio check-in della PROC_A sto committando solo quel lock.

In questo caso la sequenza con la quale avvengono le modifiche introduce una gerarchia di modifiche e relativi comportamenti differenziati al check-in.
Solo che...

... lo sviluppatore magari esegue il check-out della videata e ne modifica alcune parti; passano magari un paio di giorni, arriva poi da fare sul metodo MioMetodo(); tiziocaia lavora velocemente utilizzando as-usual le modalità di check-out automatico (e quindi non fa proprio caso al fatto che alle modifiche corrisponda effettivamente un lock/checkout).
Finita la correzione o la modifica, controlla bene col diff destrocliccando MioMetodo() - Mostra differenze
controlla
va bene
sempre tasto destro check-in e...

patatrac

crede di eseguire il check-in di MioMetodo() (del resto il diff gli ha appena visualizzato le modifiche locali, specifiche, no!?)
e invece esegue il check-in di tutta la videata, forse con modifiche che non devono rientrare o a metà lavori o...

Il punto critico e migliorabile è quello della costruzione del menù contestuale ovvero della voce Check-in per un dato elemento. Come dovrebbe essere? Così:
Nel menù contestuale appare la voce Check-in sull'elemento specifico solo se il check-out è stato specifico per quell'elemento. Nel caso in cui le modifiche siano state apportate senza eseguire check-out in quanto la modificabilità era già garantita da check-out di elemento "inglobante", la voce check-in non deve apparire (o deve essere ingrigita).

Riassumendo: la voce check-in deve apparire nel menù contestuale solo su elementi versionati sui quali è stato eseguito il lock / check-out.

Personalmente mi è capitato più volte di eseguire erroneamente check-in di videate credendo di eseguire i check-in locali, specifici di un elemento.
Del resto, non mi sembra che ci siano per uno sviluppatore per capire (agilmente) migliori dell'ingrigire o far sparire la voce Check-in su quegli elementi per i quali non è stato eseguito il lock.

[g.lanzi]

Il caso in questione è troppo specifico per poterne parlare sul forum.
Se questo genere di cose non lo vediamo in assistenza è molto improbabile riuscire a venirne a capo.

Puoi inserire una richiesta di assistenza così guardiamo insieme la cosa?