subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evgeny Kotkov <evgeny.kot...@visualsvn.com>
Subject Re: svn commit: r1682265 - /subversion/trunk/subversion/libsvn_fs_fs/util.c
Date Fri, 29 May 2015 14:54:15 GMT
Stefan Fuhrmann <stefan.fuhrmann@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

Mime
View raw message