Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes: > However, it does not tell you anything about consistency with outside > parties, say some svnsync'ed repository. The problem is that Windows may > end up not persisting the rename (of e.g. the 'current' file) after telling > the client that the commit got through and a new revision number is > available.
[...] > The two problems are mentioned: The first one is that rename itself is > obviously not persistet, e.g. the 'current' file may show the old contents > even after the server send a "commit done, new rev available" to the client. > > To reproduce: Have a "busy" server setup, do lots of commits, record HEAD > revs returned to the client on the client, pull the plug on the server and > compare HEAD on server vs. HEAD on client. In some cases, the latter should > be higher. [...] This reproduction contradicts with what I see in code. Is it a blind guess? Did you try it with this patch and without it? Our current code doesn't use the svn_fs_fs__move_into_place() when updating the db/current file contents, so I don't see how it could possibly fix the aforementioned problem. Do we *really* have a reproducible problem with single-volume renames on Windows? If there is a problem with how we handle cross-volume moves, then we should fix it, but perhaps not with doing a huge amount of unnecessary CreateFile() and FlushFileBuffers() calls in a common case in order to solve an edge case. Regards, Evgeny Kotkov
