Como consertar um repositório SVN onde ele permite o checkin do código-fonte ou dos arquivos de texto, mas não dos arquivos binários ou jars?

Question

Recentemente, recebi a tarefa de cuidar da instalação SVN de nossa empresa e, com certeza, um dos repositórios armazenados nela tem um problema.

O que eu vejo é que, se eu fizer uma nova verificação do repositório, posso fazer alterações no código-fonte e fazer o check-in sem nenhum problema, mas se eu tentar fazer check-in de um novo arquivo binário (jar ou dll) Recebo um erro dizendo que não é possível definir o ponteiro de localização para um arquivo. O arquivo está localizado no diretório '\ db \ txn-protorevs'. O erro continua explicando que o acesso foi negado.

Após algumas investigações, percebi que não estamos usando apenas o Subversion, mas o Collabnet Subversion 1.8.13 e o Collabnet Subversion Edge para gerenciamento. Esses serviços são executados em um servidor virtual na rede de nossa empresa que executa o Windows Server 2008 R2. Os próprios repositórios são armazenados não neste servidor, mas no nosso servidor de arquivos (provavelmente para fins de backup). O servidor de arquivos também é um sistema operacional Windows, mas eu não sei a versão. Isso tudo foi configurado e configurado antes de herdá-lo, e não tenho certeza se posso fazer uma alteração para colocar os serviços e os repositórios no mesmo servidor e, assim, remover a necessidade de um compartilhamento de rede, que eu foi informado é um problema para o Subversion.

Eu também comparei um repositório de trabalho com o repositório com falha e parece que o Formato do Sistema de Arquivos é diferente. O bom repositório usa a versão 3 do FSFS, enquanto o repositório com falha usa a versão 4 do FSFS.

Eu tenho direitos de administrador no servidor virtual com os serviços do Subversion, e posso acessar o compartilhamento de rede onde os repositórios estão armazenados. Portanto, executar svnadmin não é um problema. Nem todos os repositórios no nosso SVN são afetados.

Eu tentei os seguintes remédios que nenhum deles funcionou:

• Executou um svn cleanup da cópia de trabalho.
• Verificado que o usuário da conta de serviço tem acesso total às pastas do repositório.
• Criado um repositório temporário, mas o usuário ainda tinha o mesmo problema.
• Direitos de acesso comparados entre os repositórios de trabalho e os repositórios com falha, são todos iguais.
• Verificada a versão do cliente SVN da cópia de trabalho.

O que estou tentando descobrir é

1. Como posso recuperar esses repositórios para que eles possam ser usados novamente?
2. Como identificar a causa e, assim, esperamos, impedir que isso aconteça novamente?

Um pensamento seria executar um despejo do repositório, excluí-lo e criá-lo novo e, em seguida, carregar o arquivo de despejo de volta para ele. No entanto, se criar um novo repositório apenas para um check-in temporário não ajudou, não tenho certeza se a solução de despejo / exclusão / criação / carregamento o tornará melhor.

Tenho quase certeza de que a versão FSFS não é um problema, pois encontrei outro repositório da versão 4 do FSFS que também não tem o problema com arquivos binários. Eu também estive procurando nos arquivos svnserve.conf mas novamente não consigo encontrar nada que possa impedir a verificação de arquivos.

Eu atualizarei aqui enquanto tento encontrar outras possíveis razões para esse comportamento.

Encontrei uma solução alternativa, mas não sei por que isso funciona. Aparentemente, quando eu mudo o tipo MIME de um arquivo jar do padrão 'application / octet-stream' para 'application / java-archive', posso fazer o check-in do arquivo jar sem o erro. Agora, se eu soubesse por que isso funcionava, mas permitir que o Subversion usasse seu tipo MIME padrão, não.