Cosa fare se il workspace va fuori controllo

Talvolta capita, soprattutto con i workspace di tipo server server (quindi con VS2010 o precedenti) che eseguendo operazioni manuali sul file system al di fuori di VS o di Team Explorer diventi impossibile fare check-in.

Un esempio potrebbe essere: aggiungiamo un  nuovo progetto ad una solution in Visual Studio, verra marcato come “pending-add” ovvero verrà aggiunto al prossimo check-in ed avrà la sua iconcina del più accanto al nome. Ora supponiamo di chiudere il VS rinominare la cartella ed il nome del progetto direttamente dal file system, riaprire VS e ricaricare il progetto rinominato. Di base vedete sempre che la soluzione rinominata ha l’icona del  pending-add, però poi quando andate a fare check-in probabilmente vi verrà fuori un messaggio di errore che lamenta la mancanza della cartella con il vecchio nome.

Quello che succede è questo, voi aggiungete il progetto da VS, viene marcato come pending-add, poi quando lo rinominate, il workspace ha ancora memorizzato l’operazione di pending-add, ma i file non ci sono più e questo genera l’errore. Questo tipo di errori si hanno anche con altri source control, come ad esempio subversion, ed è tipico di quando si manipola il file system al di fuori dei comandi del source control.

Se vi trovate in questo tipo di errori con TFS o con subversion, la soluzione più radicale è quella di zippare tutto il contenuto della cartella, eseguire un rollback di tutte le modifiche pendenti e poi andare a unzippare il vecchio contenuto, chiaramente dopo aver fatto check-out di tutti i file se siete con un workspace lato server.

Alternativamente potete effettuare un tfpt scorch (comando dei power tools) e verificare se questo vi risolve il problema (dipende dal tipo di disallineamento che è avvenuto). Ho bloggato la sintassi del comando un po di tempo fa :) se vi servissero informazioni le trovate qui.

Se questo non bastasse potete cancellare completamente la cartella dove è avvenuto il “fattaccio” (ovvero la cartella che contiene i file con gli errori) ed eseguire un get specific version per recuperare di nuovo tutto il contenuto, a quel punto verificare se avete ancora operazioni pendenti e fate undo di tutto, poi procedete a unzippare il backup.

Se invece volete essere meno radicali, dopo avere zippato tutto per evitare di perdere le modifiche, aprite il Team Foundation Server sidekick (se non lo avete è un tool gratuito che potete scaricare qui). Dal sidekick potete verificare lo stato del workspace nel server (per i workspace lato server) e potete annullare eventuali operazioni pendenti che sono errate (ad esempio di parti di progetto che avete rinominato).

Di base però cercate di evitare la manipolazione del file system al di fuori dei comandi del source control utilizzato, ad esempio installate sempre i power tools con l’integrazione con l’explorer, cosi se dovete agire al di fuori del Visual Studio sui file potete farlo con gli appositi comandi, senza correre il rischio di “incasinare” il workspace.

Gian Maria

One Response to Cosa fare se il workspace va fuori controllo

  1.