No post anterior aqui no blog, mostrei como resolver via console o desbloqueio de arquivos depois que um funcionário sai da empresa e sua máquina não está mais inacessível; ou quando alguém sai de férias e deixa arquivos em lock. O cenário é o mesmo, então vou repetir o pedido de consultoria de um amigo meu aqui:
Brandão, um dev foi demitido e deixou vários arquivos de código com lock, a máquina já foi formatada pela Infra e não dá mais para entrar nela para liberar, o que eu faço?
Mas a solução será diferente, console, mas com Powershell.
Vamos chamar o desenvolvedor dispensado de John Doe. E quem reportou o problema foi o Brian K., aconteceu o seguinte, quando ele foi fazer o check-out do arquivo para edição:
Abriu uma janela com duas opções:
Ele escolheu a primeira e tudo deu certo, o arquivo foi marcado como check out, pois não foi preciso criar locks:
Aparece o sinal vermelho, como um ‘v’, indicando que está em check out, e portanto só prosseguir com a edição.
Se o Brian tivesse escolhido a segunda opção:
O arquivo iria ser marcado com lock, para impedir outros usuários de editarem o arquivo, e daí o seguinte erro apareceria:
No primeiro caso o erro iria acontecer quando fosse feito o check in!
Nada novo, para quem leu o post anterior, certo? Então vamos a solução com Powershell.
Power Tools Cmdlets
O instalador do Power Tools sugere a instalação dos Cmdlets no wizard, se você esqueceu de marcar essa opção modifique a instalação através do Painel de Controle.
Para verificar se os Cmdlets estão instalados, execute o seguinte comando:
Get-PSSnapin –Registered
Se não aparecer o Microsoft.TeamFoundation.PowerShell registrado, é só adicionar, confira em seguida com o comando anterior:
Add-PSSnapin Microsoft.TeamFoundation.PowerShell
Conectando com o Tfs
Para conectar com o TFS vamos usar o CmdLet Get-TfsServer, são necessários
- Name: é a URL da Collection
- Credential: Objeto Credential do Powershell, opcional
O retorno será armazenado em uma variável para usarmos no próximo comando, execute:
$TfsServer = Get-TfsServer -Name http://vsalm:8080/tfs/FabrikamFiberCollection
Localizando arquivos com lock
Para sabermos todos os arquivos que o John deixou com lock, vamos executar o seguinte comando:
Get-TfsPendingChange -Server $TfsServer –User “vsalmjohnd”
O parâmetro User indica o usuário alvo da busca de objetos pendentes ou com lock.
O retorno do comando mostra apenas os arquivos e seus status, em ChangeType, como “Edit, Lock”.
Retirando o lock do arquivo
Para retirar o lock podemos usar Remove-TfsPendingChange, com os seguintes parâmetros:
- Item: arquivos para retirar o Lock
- Workspace: local onde o arquivo está pendente
A informação para os dois parâmetros encontramos no objeto de retorno do comando anterior, para verificar execute o seguinte comando:
Get-TfsPendingChange -Server $TfsServer -User “vsalmjohnd” | fl *
fl é alias de Format-List, que formata a saída colocando uma propriedade por linha. Daí podemos encontrar o que precisamos:
- PendingSetName: nome do workspace, atenção, aqui neste exemplo ele tem o mesmo nome da máquina, não é o nome do domínio nesta propriedade
- PendingSetOwner: domainuser
- ServerItem: Caminho do arquivo no servidor
Infelizmente o CmdLet Remove-TfsPendingChange não aceita essas propriedades via Pipe, “|”, que é uma feature muito interessante do Powershell, que permite encadeamento de CmdLets.
Se você quer aprender mais sobre Powershell, comece por este e-book FREE
Portanto podemos usar o pipe, para iterar a saída dos aquivos com lock, e passamos os parâmetros para o Remove-TfsPendingChange “na mão”, execute:
Get-TfsPendingChange -Server $TfsServer -User "vsalmjohnd" | % { Remove-TfsPendingChange -Item $_.ServerItem -Workspace ($_.PendingSetName + ";" + $_.PendingSetOwner) }
Problema: o erro retorno quer dizer que o comando não conseguiu localizar o servidor de controle de versão.
Para resolver esse problema podemos inferir essa localização, se o workspace estiver mapeado na máquina em que o comando estiver sendo executado. Execute o mesmo comando, mas agora no diretório do workspace alvo, veja na imagem:
A mensagem “The operation completed successfully. Because the workspace VSALM;John Doe is not on this computer, you must perform a separate get operation in that workspace to update it with the changes that have been made on the server.” diz que foi executado, mas como o workspace alvo não está na máquina então é preciso executar novamente um get para atualizar o workspace que estamos.
Para validar é só executar Get-TfsPendingChange:
Get-TfsPendingChange -Server $TfsServer -User “vsalmjohnd”
Emmanuel Brandão