> -----Original Message----- > From: Hans-Emil Skogh [mailto:hans-emil.sk...@tritech.se] > Sent: woensdag 11 mei 2011 10:03 > To: dev@subversion.apache.org > Subject: WC-NG, externals and fast properties > > 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.
The problem is much bigger then you describe here and the performance is a nice side effect, but not related to the real issue. There are some old threads that explain more of the reasoning why it works like this today. There are fundamental problems with how we have to process the svn:externals property: we need the version *exactly* how it was at the last svn update and the 'latest' version, to make the svn:externals processing handle definition changes. (We really need the *CHANGES of externals*...) By moving properties into another database we don't fix this. We still only have how they were 'some time ago' and how they are in the 'latest' version. Where in this case latest might have local changes. But we still don't have the changes. (And even then the svn:externals would then be a text stream in a different table. So that wouldn't help too) By going back to the original Subversion 1.0-like behavior of handling only committed properties we had the information what the svn:externals were last time, and what the new externals are now. So this fixes issues like where we can't remove file externals. But at the cost of not allowing local changes to svn:externals. Which is not nice. The solution here is not to move properties to a different database. (Which is not really not going to help us anyway, because all our layers assume that we process all properties on a node at once) But the real solution is to add a store which contains what externals we knew at the last update. And I'm working on that right now. Once that store is operational (guess: by the end of this week), we can safely re-enable local changes to svn:externals, but without the problems of the past. Bert