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

RE: svn commit: r1411982 - in /subversion/branches/1.6.x: ./ STATUS subversion/libsvn_client/commit_util.c subversion/libsvn_fs_fs/fs_fs.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 22 Nov 2012 10:03:31 +0100

> -----Original Message-----
> From: Ben Reser [mailto:ben_at_reser.org]
> Sent: donderdag 22 november 2012 02:52
> To: Bert Huijben
> Cc: Subversion Development
> Subject: Re: svn commit: r1411982 - in /subversion/branches/1.6.x: ./
> subversion/libsvn_client/commit_util.c subversion/libsvn_fs_fs/fs_fs.c
> First of all thanks for asking these questions, my effort to answer
> them gave me even more confidence in the changes.


> No I don't think this change breaks anything for anyone.
> We could remove the client change now as it really doesn't have any
> impact. But it's a valid change for other reasons as mentioned above,
> so we might as well leave it.
> Even without the client library change you're still touching the
> client. The solution I'm using here is a fix to the fsfs layer.
> Which when using ra_local the client is the server. Moving the fix up
> to mod_dav_svn is much harder.
> Ultimately the problem here is that the fs is receiving the
> representation of a node via a window handler. The window handler
> only has two things you can tell it. 1) Here is some data. 2) There
> is no more data. As such there is no way for mod_dav_svn to
> communicate to the fs layer that the representation I sent you is
> incomplete. Additionally, the whole thing is driven through the
> svndiff parsing code, which has an option (error_on_early_close) to
> say error if the svndiff looks incomplete. If this option is true
> then the window handler is never called with NULL for the window
> (we've reached the end of the data). Setting this flag to FALSE would
> make that call happen but then fsfs would have no idea that we feed it
> incomplete data, thus adding an invalid representation to the protorev
> file.
> Long term the fix is probably refactoring some public interfaces. But
> that's not a very attractive option for backport. Nor am I in a huge
> hurry to do it since I think making these changes is going to cascade
> out into a lot of other code.

Thanks for this in-depth answer.

The fact that it just improves the client further is the answer that I was
hoping for.
(Theoretically it is a separate improvement)

This explanation would make me add my +1 to the backport, but we already got
the required votes.

Received on 2012-11-22 10:04:10 CET

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