Passando da Team Foundation Server 2010 a Team Foundation Server 2013 ci sono alcune cose che vengono automaticamente configurate per default sulla gestione del Source control e sono le seguenti:
- Il workspace creato dal programmatore sulla sua macchina è per default Private e sempre per default Local
- Private = nessun’altro sulla stessa macchina può usare lo stesso workspace per lavorare.
- Local = l’utente lavora sempre disconnesso dal server, quindi il checkout e checkin non sono mai lockati sul server pertanto è possibile editare lo stesso file in 15 persone contemporaneamente.
- I progetti TFS, per default hanno il checkout multiplo abilitato
- Disabilitando il checkout multiplo, a causa delle opzioni precedenti comunque non cambia nulla, perché il server annota il checkout ma non blocca nulla.
Se le regole aziendali impongono che:
- Ogni file debba essere bloccato quando una persona lo modifica
- Nessuno quindi può modificare in contemporanea lo stesso file
Logica vuole che un amministratore di TFS esegua le seguenti operazioni:
- Disattivi il flag di checkout multiplo
- Modifichi i workspaces in modo che siano Server invece che Local
- Se necessario, faccia divenire pubblico il workspace su una macchina per renderlo usabile a più utenti.
Fatto questo, si assume che quando un file viene modificato da un utente, il checkout dello stesso (usualmente impostato come automatico in Visual Studio) provochi il blocco del file su TFS
in modo che un solo utente per volta possa modificarlo.
Sfortunatamente, tutto questo non succede, il file risulta in Checkout, ma può essere comunque aperto contemporaneamente da più utenti e al checkin se due utenti lo hanno modificato sarà necessario il merge, il secondo utente che ha fatto il checkout non viene bloccato.
Come si fa quindi a bloccare un file in modo esclusivo?
Metodo 1, modello Giuditta:
Costringere i propri utenti a un lavoro in più (e far si che dopo una settimana sparino all’amministratore di TFS e al project managere gambizzino l’amministratore delegato (oppure disattivino l’opzione scavalcando la regola aziendale)):
- In Visual studio 2013: Tools, Environment, Source control
- Attivare l’opzione Prompt for lock on checkout
Metodo 2, Drastico ma funzionale:
- In team explorer aprire la sezione Setting (è necessario essere amministratori)
- Aprire la sezione Source Control sotto Team Project Collection
- Modificare l’opzione Enable File Merging per tutti i tipi di files per cui si vuole il lock esclusivo.
Il fatto che non sia possibile (come era fino a TFS2010) semplicemente scegliere di disattivare l’editing multiplo per ottenere il lock esclusivo, non sappiamo per quale motivo non vi sia più, quello di cui siamo felici, è che sia possibile ancora farlo.
Non vogliamo entrare in merito alle motivazioni, che reputiamo certamente dettate dalla flessibilità e dalla possibilità di gestire team di lavoro distribuiti e disconnessi in cui prima TFS era un po’ carente. La scelta di permettere la modifica senza Lock e il conseguente obbligo al Merge nel caso di modifiche concorrenti, è a nostro avviso qualcosa che deve essere deciso a livello aziendale o di Team Management.
Che sia pratica buona o meno buona non abbiamo la competenza per dirlo.