Eu tenho um repositório de subversão com
"SVNAutoversioning on"
que geralmente permite que clientes webDAV façam alterações em arquivos sem um ciclo checkout-edit-commit, e isso funciona bem para alguns subconjuntos do repositório por conveniência. Neste exemplo, estou usando o subversion para versionamento centralizado, em vez de controle de origem.
O servidor zerar os arquivos intermitentemente, geany / gedit oferece um recarregamento (o que eu aprendi é um não-não) e o arquivo recarregado está vazio. Eu pensei que poderia ser algo para fazer com arquivos temp gtk, mas é replicável com o vi ou kate.
Se eu editar um arquivo no vi, aqui está o exemplo da confirmação de sucesso;
"mnt/here/bootstrap.d/edited-file"
110L, 4077C written
e listagem confirma que o arquivo tem tamanho diferente de zero;
> ls -la mnt/here/bootstrap.d/edited-file
-rw-r--r-- 1 me me 4.0K Jan 11 07:42 mnt/here/bootstrap.d/edited-file
no entanto, alguns segundos depois, a listagem é alterada mostrando o zeramento do arquivo
> ls -la mnt/here/bootstrap.d/edited-file
-rw-r--r-- 1 me me 0 Jan 11 07:42 mnt/here/bootstrap.d/edited-file/chef-client
O registro do repositório svn mostra algumas transações que são presumivelmente responsáveis.
==> svn.limepepper.co.uk-error.log <==
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' MOVE projects:/some/path/in/repo/this-file-gets-zeroed projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' MOVE projects:/some/path/in/repo/this-file-gets-zeroed~ projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:06 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' HEAD projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:07 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' LOCK projects:/some/path/in/repo/this-file-gets-zeroed
==> svn_logfile <==
[11/Jan/2012:01:47:07 -0600] service lock (/some/path/in/repo/this-file-gets-zeroed)
==> svn.limepepper.co.uk-error.log <==
[Wed Jan 11 01:47:07 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' DELETE projects:/some/path/in/repo/this-file-gets-zeroed~
[Wed Jan 11 01:47:07 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' GET projects:/some/path/in/repo
[Wed Jan 11 01:47:19 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' PUT projects:/some/path/in/repo/this-file-gets-zeroed
[Wed Jan 11 01:47:20 2012] [info] [client 87.194.yyy.xxx] Access granted: 'service' UNLOCK projects:/some/path/in/repo/this-file-gets-zeroed
==> svn_logfile <==
[11/Jan/2012:01:47:20 -0600] service unlock (/some/path/in/repo/this-file-gets-zeroed)
O svn repo DAV é montado como:
http://myserver/pathtorepo on /home/me/mnt/mountedhere type fuse (rw,nosuid,nodev,noexec,relatime,user_id=500,group_id=500,allow_other,max_read=16384)
The server details are;
# rpm -qa | egrep "httpd|mod_|subversion|dav|neon"
httpd-tools-2.2.17-1.fc14.i686
httpd-2.2.17-1.fc14.i686
mod_auth_mysql-3.0.0-12.fc14.i686
mod_perl-2.0.4-11.fc14.i686
mod_python-3.3.1-14.fc14.i686
httpd-manual-2.2.17-1.fc14.noarch
subversion-libs-1.6.17-1.fc14.i686
subversion-1.6.17-1.fc14.i686
mod_dav_svn-1.6.17-1.fc14.i686
neon-0.29.5-1.fc14.i686
mod_ssl-2.2.17-1.fc14.i686
Eu decidi demitir usando o DAV montado, pois ele parece ser terrivelmente não confiável, mas eu estaria interessado em resolver o problema como algo que usei aqui e ali anteriormente.