TW: richiesta lock troppo pervasiva

[t.simoncini]

Proseguo (in un certo senso) la discussione su TeamWorks che era stata iniziata qui (viewtopic.php?f=5&t=70768)

Abbiamo dei grossi problemi con i lock. Siamo 4 programmatori che lavorano sullo stesso progetto.
Capita (minimo una volta al giorno) di doversi bloccare nel lavoro a causa di un operazione non effettuabile perché un collega ha già un lock su qualcosa molto spesso neanche collegata.

Faccio un esempio così si capisce meglio.
Ho una vista che si chiama ArticoliView, che raccoglie tutte le informazioni degli articoli e delle tabelle collegate che possono tornare utili in una vista (decodifiche di categorie, ecc...).
Ho creato una classe DO basata su questa vista (perchè mi serve usare la DO per n motivi), e uso questa classe nelle lookup e in varie procedure delle varie videate.

Se ho necessità di aggiungere un nuovo campo alla vista, vengono presi i lock su tutte procedure dove è usata la classe. Quindi, se un mio collega ha preso un lock su uno di questi oggetti, io mi posso attaccare al tram.
Mi hanno spiegato il motivo di questo comportamento: aggiungendo una proprietà alla classe, si modifica la sua interfaccia, e quindi anche ogni punto in cui è potenzialmente usata. Concettualmente lo posso capire, ma nella pratica non sta in piedi. Se aggiungo una proprietà ad una classe DO, quale danno potrei fare in qualsiasi punto è usata? Potrei capire la cancellazione, ma l'inserimento??

Questo è solo un caso di esempio. Ci sono mille altre situazioni che capitano tutti i giorni che costringono nel migliore dei casi a fermarsi e fare qualcos'altro nell'attesa che il collega faccia il check-in (spesso di cose sviluppate a metà) per sbloccare il lavoro.

La mia domanda è: siamo i soli ad avere questi problemi?
E come si pone ProGamma di fronte a questa situazione?
Io sono disposto anche a spendere del tempo per segnalare le situazioni secondo me migliorabili, ma solo se effettivamente poi viene fatto qualcosa.

Attualmente, per noi, lavorare con TeamWorks, significa fare almeno un Check-In/GetLatest al giorno. Solo per poter lavorare. Non è comodo. E anche dispendioso in termini ti tempo (tempo = $).

[r.bianco]

Sì, capita anche a noi.
Devo dire però che ho la sensazione che il nodo sia (per noi): non lo stiamo usando nel modo in cui è stato pensato.

[t.simoncini]

non lo stiamo usando nel modo in cui è stato pensato

In che modo è stato pensato? Mi risulta che INDE (Foundation) abbia come obiettivo di essere una valida alternativa a strumenti tradizionali (Visual Studio, Eclipse) per lo sviluppo anche in team.

[manuel]

Lavoro su un progetto gestito da TW e siamo due programmatori, e anche così capita che si blocchi il lavoro a causa di un lock.
Personalmente preferirei un sistema in cui la modifica ad un oggetto non prende un lock, e che mi consenta in fase di check-in di risolvere eventuali conflitti.

[r.bianco]

@t.simoncini:
L'idea che mi sono fatto è che TW sia pensato per un flusso chekout/checkin granulare e non massivo. In altre parole, se per arrivare al risultato dobbiamo effettuare 15 modifiche al progetto, di ogni modifica dovrà essere fatto il checkin prima di effettuare il checkout per la modifica successiva. Per svariate ragioni, difficilmente (noi) riusciamo ad applicare questa gestione e ci troviamo ad avere metà progetto bloccato, con la necessità di effettuare un checkin 'intermedio' per sbloccare la situazione.
E` solo un esempio, e soprattutto solo un'impressione. Sono interessato anch'io alla risposta ufficiale dalla 'sala di comando'.

[morris]

@t.simoncini:
L'idea che mi sono fatto è che TW sia pensato per un flusso chekout/checkin granulare e non massivo. In altre parole, se per arrivare al risultato dobbiamo effettuare 15 modifiche al progetto, di ogni modifica dovrà essere fatto il checkin prima di effettuare il checkout per la modifica successiva. Per svariate ragioni, difficilmente (noi) riusciamo ad applicare questa gestione e ci troviamo ad avere metà progetto bloccato, con la necessità di effettuare un checkin 'intermedio' per sbloccare la situazione.
E` solo un esempio, e soprattutto solo un'impressione. Sono interessato anch'io alla risposta ufficiale dalla 'sala di comando'.

Allineare InDe agli altri strumenti di sviluppo e allineare TeamWorks agli altri strumenti di versioning esistenti sul mercato è il primo errore, anche se è oggettivamente difficile non commetterlo. Quanto sostiene Bianco è verissimo e fra l'altro si allinea moltissimo a quelle che sono le comprovate "buone abitudini" di sviluppo in team anche con gli altri strumenti di sviluppo/versioning: vale a dire, modifiche granulari e checkin molto frequenti di cose più atomiche possibili, attraverso l'adozione di strategie bottom-up, quindi più testabili, prima che top-down, che al contrario dilatano molto il numero di sorgenti coinvolti in un blocco da committare e rendono anche più difficile la navigazione della storia delle modifiche, per esempio. Non dimentichiamo inoltre che InDe non ha sorgenti singoli, ma catene di legami relazionali per cui il lock viene giocoforza "spalmato" su tutti i punti coinvolti dal legame con l'oggetto che noi abbiamo di fronte durante l'editazione. Nel lavoro in team, probabilmente, diventa più importante la fase di assegnamento delle priorità delle modifiche che la realizzazione stessa, al fine di garantire la possibilità di un lavoro contemporaneo tra colleghi su argomenti distinti. Nel caso specifico in oggetto, purtroppo, la vista raccoglie molti di queste "catene relazionali" per cui mi rendo conto che la modifica ad essa o al documento collegato debba essere fatta a bocce ferme. Dubito tuttavia che dalla 'sala di comando' possano ovviare a questo limite se non introducendo forti rischi o controlli manuali in fase di checkin successivo.

[t.simoncini]

le comprovate "buone abitudini" di sviluppo in team anche con gli altri strumenti di sviluppo/versioning: vale a dire, modifiche granulari e checkin molto frequenti di cose più atomiche possibili, attraverso l'adozione di strategie bottom-up, quindi più testabili, prima che top-down, che al contrario dilatano molto il numero di sorgenti coinvolti in un blocco da committare e rendono anche più difficile la navigazione della storia delle modifiche, per esempio.

Permettimi di non essere d'accordo.
Se mi viene chiesto di implementare una nuova funzionalità, vorrei prendermi la mia settimana/15 gg (o il tempo che serve) per svilupparla, provarla, testarla e validarla prima di spedirla su TW e ai miei colleghi.
Non voglio correre il rischio di condividere modifiche parziali che rendono il software non funzionante e/o non distribuibile.

Ho lavorato per anni con CVS, e conosco bene Git. Sono estremamente efficienti ed efficaci. Mai avuto un problema, anche se la situazione è diversa, lì si lavora su codice testuale, dove la risoluzione di conflitti è facile.

Allineare InDe agli altri strumenti di sviluppo e allineare TeamWorks agli altri strumenti di versioning esistenti sul mercato è il primo errore

Se INDE si vuole proporre come una valida alternativa (senza necessariamente essere migliore), non è il primo errore, ma la prima considerazione da fare.

L'obiettivo di tutti penso sia avere uno strumento migliore: da vendere (per ProGamma) e da usare (per noi).

[t.simoncini]

Nessuno di ProGamma partecipa alla discussione?

[g.lanzi]

Per quanto riguarda la gestione dei lock, potreste tranquillamente lavorare in modalità renegade senza darvi fastidio, prendendo i lock subito prima del check-in e risolvendo manualmente evenuali confliti. Personalmente non lo ritengo molto comodo, ma è una questione anche di gusti.
In ogni caso, basta disconnettere (non disabilitare, eh, disconnettere) TW e quando si prende un lock specificare la scelta di mezzo sui lock offline.

Per quanto riguarda la risposta ufficiale della sala di comando, non la voglio dare ora. Mi interessa vedere se qualcun altro raccoglie la discussione e ci dà altri contributi. Il primo scopo della community è proprio raccogliere il parere dei diversi utilizzatori di Instant Developer. Avere un thread con pareri non allineati è per noi una grande ricchezza, che non intendo perdermi :)