[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1682265 - /subversion/trunk/subversion/libsvn_fs_fs/util.c

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Fri, 29 May 2015 17:54:15 +0300

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.

Evgeny Kotkov
Received on 2015-05-29 16:55:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.