Quando si utilizza Plastic SCM, oggi chiamato Unity Version Control, cancellare un file dal workspace e fare un check-in non significa cancellarlo dalla cronologia del repository.
Il file rimane infatti disponibile nelle vecchie revisioni e può continuare a occupare spazio sul server.
Se, ad esempio, abbiamo committato per errore un grosso per mesi, la normale cancellazione del file non è sufficiente ma dobbiamo utilizzare invece il “temibile” comando cm purge.
Attenzione: il purge è un’operazione distruttiva e irreversibile. Unity specifica che, una volta eseguito, le revisioni purgate non possono più essere caricate. Prima dell’esecuzione è quindi fondamentale verificare esattamente cosa verrà eliminato.
Cancellare un file dal repository non è sufficiente
Supponiamo di avere un file /Build.zip committato decine di volte nei commit precedenti, anche dopo averlo cancellato dal un commit la cronologia continuerà a contenere tutte le precedenti revisioni.
Per poterlo purgare è necessario individuare l’ITEM ID di quel file attraverso il comando da Command Prompt (con privilegi di amministratore) CM FIND, in questo modo:
cm history "serverpath:/nomefile.zip#cs:numerocommit@nomerepository@dominio@cloud" --format="{1} | REV={6} | ITEM={12} | {0} | {13}"
Un esempio di comando completo può quindi essere il seguente:
cm history "serverpath:/Build.zip#cs:101@Hellpath@desdinovait@cloud" --format="{1} | REV={6} | ITEM={12} | {0} | {13}"
Verrà mostrata una lista di tutte le revisioni fatte di quel file per tutta la storia del repository, con date e dimensioni. Quello che è necessario verificare è la colonna dell’ITEM ID che riporterà sempre lo stesso valore. Prendiamo nota di quel valore perchè è univoco in tutto il repository e necessario per la cancellazione.
Attenzione alla differenza tra revision ID e item ID
È importante non confondere questi due valori.
Il revision ID identifica una specifica revisione e cambia ogni volta che il file viene modificato.
L’item ID, invece, identifica l’item e rimane associato al file attraverso le sue revisioni.
La sintassi di registrazione, che ritornerà un GUID, è:
cm purge register "<estensione>" "<data>"
La documentazione ufficiale specifica che il comando register seleziona le revisioni appartenenti a una determinata estensione e precedenti alla data indicata. Inoltre vengono mantenute alcune revisioni necessarie, come almeno una revisione per ogni branch head e le revisioni etichettate.
Nel nostro esempio:
cm purge register ".zip" "2026-Feb-01" --repository="hellpath@desdinovait@cloud"
Controllare il purge prima di eseguirlo
Il comando purge register restituisce un GUID, ad esempio:
1024cc86-7d9c-4a81-36a4-82944b21071b
Possiamo quindi analizzare il purge con il comando seguente
cm purge show 1024cc86-7d9c-4a81-36a4-82944b21071b --verbose
L’opzione –verbose è particolarmente importante perché mostra gli item e le revisioni coinvolte con le dimensioni di cancellazione (spazio che guadagneremo sul repository in cloud).
Se il purge show --verbose mostra file che non vogliamo eliminare, non bisogna eseguire il purge.
Un purge registrato ma non ancora eseguito può essere rimosso con:
cm purge unregister 1024cc86-7d9c-4a81-36a4-82944b21071b
Eseguire definitivamente il purge
Quando abbiamo verificato attentamente l’elenco, possiamo eseguire:
cm purge execute 1024cc86-7d9c-4a81-36a4-82944b21071b
ATTENZIONE: Questa operazione non è reversibile.
Come verificare che il purge sia realmente avvenuto
Possiamo consultare la cronologia dei purge tramite il comando history:
cm purge history --verbose
Questo comando permette di verificare lo stato delle operazioni di purge eseguite sul server e conserva informazioni come data, autore, dimensione e tipologia dei dati coinvolti.
Perchè cm find revision continua a mostrare le vecchie revisioni?
Dopo il purge potremmo ancora vedere le revisioni nei risultati di:
cm find revision "where itemid = 34996 on repository 'Hellpath@desdinovait@cloud'"
Questo non significa necessariamente che i dati del file siano ancora disponibili.
La verifica decisiva è tentare di recuperare il contenuto di una revisione che sappiamo essere stata purgata.
Nel nostro esempio:
cm cat revid:34957@Hellpath@desdinovait@cloud
il comando resituirà:
Can't retrieve the content of the file ...
because the revision (id:34957) was purged
and its content is no longer available.
Questa è la conferma concreta che il contenuto della revisione è stato effettivamente rimosso.
