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,
Hans-Emil

* 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...

Reply via email to