Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: 
 <CA+t0gk2_d5M1AC=0uiZ=ubznDnMukSfbyAXQrhhcX1BuoXfyzA@mail.gmail.com>
References: <20150528154555.D1D0BAC06F9@hades.apache.org>
 <CABw-3YerzerVqW1CdYYm8vbWRuKy3-EAKrhmO=xb7OY=S8ETzw@mail.gmail.com>
 <CA+t0gk3yQm+nYgH4C_Lu=fGMFShojEiwbZ05rb=CnhoHFpv5DQ@mail.gmail.com>
 <CABw-3YehnUheqHgq9PbLPyh65xdYQWDXvahurfW1KOTkQmc5nA@mail.gmail.com>
 <CABh03ad1oaAXEc08Lw_NFdxJNjbOBh212jqKLPtvq+v-aJnmHQ@mail.gmail.com>
 <556781e4.4934c20a.3e9c.025a@mx.google.com>
 <CA+t0gk2_d5M1AC=0uiZ=ubznDnMukSfbyAXQrhhcX1BuoXfyzA@mail.gmail.com>
From: Evgeny Kotkov <evgeny.kotkov@visualsvn.com>
Date: Fri, 29 May 2015 17:54:15 +0300
Message-ID: 
 <CAP_GPNhbnMubggJ_noVExkcyJM2QVjgCftEBM8upB83O7FoMCA@mail.gmail.com>
Subject: Re: svn commit: r1682265 -
 /subversion/trunk/subversion/libsvn_fs_fs/util.c
To: Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>
Cc: Bert Huijben <bert@qqmail.nl>,
 =?UTF-8?Q?Branko_=C4=8Cibej?= <brane@wandisco.com>,
	Ivan Zhakov <ivan@visualsvn.com>,
	"dev@subversion.apache.org" <dev@subversion.apache.org>,
 Stefan Fuhrmann <stefan2@apache.org>
Content-Type: text/plain; charset=UTF-8

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