svn commit: r1408325 - /subversion/branches/wc-collate-path/subversion/libsvn_subr/sqlite.c - Subversion development

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion svn commit: r1408325 - /subversion/branches/wc-collat e-path/subversion/libsvn_subr/ sqlite.c
Received-SPF: pass (google.com: domain of dev-return-22682-subversion-development+garchive-20679=googlegroups....@subversion.apache.org designates 140.211.11.3 as permitted sender) client-ip=140.211.11.3;
Mailing-List: contact dev-h...@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
From: "Bert Huijben" <b...@qqmail.nl>
To: =?utf-8?Q?Branko_=C4=8Cibej?= <br...@apache.org>,
	<d...@subversion.apache.org>
References: <20121112153648.7ED082388...@eris.apache.org>
In-Reply-To: <20121112153648.7ED082388...@eris.apache.org>
Subject: RE: svn commit: r1408325 - /subversion/branches/wc-collate-path/subversion/libsvn_subr/sqlite.c
Date: Mon, 12 Nov 2012 17:11:38 +0100
Message-ID: <020101cdc0f0$660c0440$32240c...@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEUjRRFMRL4aat5A22ZEXKwyl6aL5lYwpDQ
Content-Language: nl



> -----Original Message-----
> From: br...@apache.org [mailto:br...@apache.org]
> Sent: maandag 12 november 2012 16:37
> To: comm...@subversion.apache.org
> Subject: svn commit: r1408325 - /subversion/branches/wc-collate-
> path/subversion/libsvn_subr/sqlite.c
>=20
> Author: brane
> Date: Mon Nov 12 15:36:47 2012
> New Revision: 1408325
>=20
> URL: http://svn.apache.org/viewvc?rev=3D1408325&view=3Drev
> Log:
> On the wc-collate-path branch: Enable GLOB and LIKE operator
> replacements.

Completely unrelated to this patch, but I'm still wondering what your =
total approach/plan on this branch will be.

I can see that we handle this collate in sqlite (even though this breaks =
using a plain sqlite3 as tool on wc.db, etc.), but the =
notes/unicode-composition-for-filenames describes several other problems =
that need a fix at the same time in order not to break at least some =
current subversion users.

One of these things is that we use hashtables to represent all nodes in =
a directory in several places. In some cases we get this from the =
working copy, in some cases from the db and in even other cases from the =
repository. Some of these may be normalized in some way, while others =
are not (especially with our compatibility guarantees within 1.X)

I'm afraid that just getting wc.db compatible with normalization will =
just shift the problem one layer, while still not fixing the real =
problem. Erik Huelsmann thoroughly investigated this problem space some =
years ago and he documented that fixing the wc library is not enough for =
fixing the generic case. And if we are not fixing the generic case, I'm =
wondering if we should really work on a major slowdown of every common =
operation.

We currently have a binary format, that can be used as a hash key, so =
many comparison and lookup operations are constant time.
I'm not sure how they are after installing the collate handling.


If we leave the generic case, there are easier ways to resolve this =
issue. One such thing would be to make apr (or a wrapper in Subversion) =
normalize the on disk paths in the other direction and deny (on the =
server) the non-normalized paths. This would eliminate the slowdown on =
most use cases that don't have a problem right now, and keep the code =
clean for future problems.

If we have to check for collate handling everywhere in libsvn_wc and =
libsvn_client we make it much harder for outside developers to create =
patches and even fewer core subversion developers would dare touch these =
layers.



I'm glad somebody is finally looking into these issues, but I think we =
should look at the full picture before we can talk about getting this =
back on trunk.

	Bert
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
