Stefan Fuhrmann <stefan.fuhrmann_at_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
Received on 2015-05-29 16:55:30 CEST