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

RE: WC-NG, externals and fast properties

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 11 May 2011 10:47:55 +0200

> -----Original Message-----
> From: Hans-Emil Skogh [mailto:Hans-Emil.Skogh_at_tritech.se]
> Sent: woensdag 11 mei 2011 10:03
> To: dev_at_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
Received on 2011-05-11 10:48:34 CEST

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.