WC-NG, externals and fast properties
From: Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se>
Date: Wed, 11 May 2011 08:02:58 +0000
Hi all!
I noticed recently that the behavior when working with externals have changed in SVN 1.7. Local changes to the svn:externals property in the working copy is by default not honored during an update, before a commit. I think this is quite unfortunate.*
As I understand these changes were made because of performance reasons introduced with the WC-NG.
When looking at the database in the working copy I can see why. The properties for each node is stored as a single string. (The "properties" field in the "NODES" table.) Doing a search for all externals in a working copy will then be quite expensive.
I would suggest to add a new table for properties, similarly to how locks are handled, in order improve the speed of handling properties on nodes.
For example the table could be named "PROPERTIES" and have the fields "repos_id", "repos_relpath", "property_name" and "property_value".
This would make it possibly to relatively quickly find all nodes with externals properties in a working copy and therefore make it possible to re-enable the honoring of local modifications to externals properties by default, and thereby avoid a change in SVN behavior.
The only downside I can see is one more table, and therefore a marginally larger WC database. But that is a quite small price to pay IMHO. Am I missing any other potential downsides?
I think this would be a desirable change over all as well as it will greatly improve the speed of finding nodes with certain properties, which could make future features that makes use of properties easier/feasible.
Would this be a viable solution, or am I missing some part of the big picture here?
Best regards,
* Not honoring local svn:externals changes makes it more difficult to work with externals. One has to remember to call update with the correct flag after changing the property, otherwise the change won't have any effect. If one forgets to add the flag to the update call everything might seem to work alright, but after the commit when the external will be updated one realizes that the commit was broken... It's also not always easy/cheap to educate all the users about such changes in behavior...
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.