Morning, After experiencing some weird issues with our working svn repository. we would like to see if anybody can shed some light on how this happened, the fix ended up being doing an svnadmin dump and svnadmin load in a new repository. But, what really puzzled us is the why and how, any ideas regarding this incident would be greatly appreciated and help us to (hopefully) avoid a repeat of this incident.
Our repository was working fine for years but, one afternoon after one of our developers made a simple commit, nobody else could update from the repository. we started getting "Decompression of svndiff data failed". Simple google searches pointed us to this: http:// www.szakmeister.net/blog/fsfsverify/ but that did not solve our issues. Now, you might think we lost our collective heads, but after doing a resync -av /BrokenRepo/ /RepoCopy and ensuring that the revision file that was having the problem had the right owners, permissions, didn't have any weird ACLs or metadata attached, and the timestamps where the right ones with touch -t <TIMESTAMP> rev_file for the revision in the repository copy, suddenly the revision in the copy started passing verification, so we replaced that file in the original repository and all was well... for 2 hours or so, after the same developer committed again a test file, we started getting a new error "Revision file lacks trailing newline". We ended up fixing it the way I described above, but we don't really understand what happened or what was wrong. Our svn version on the server is: svn --version svn, version 1.6.5 (r38866) compiled Oct 16 2009, 02:54:10 The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme this is the default install on Mac OS X Snow Leopard Server (10.6.4). the developers are using Versions.app 1.0.9_79 (http:// versionsapp.com/), the subversion library it uses internal is 1.6.9. Once again, if anyone has any idea on what to check or can shed some light on this issues, please let us know. Luis R. Rojas SysAdmin Rogue Research Inc T: (514) 284-3888 F: (514) 284-6750 l...@rogue-research.com
