They would have to live in a layer below base if we want them in nodes
(op depth -1 or MAXINT?)
And there are only a few places where we do want to see them. Certainly
not as just another node in a directory, but only accessible directly
via its path. They are 'external' and really from a different
world/origin and unrelated for all wc handling except conflicts.
They don't belong in BASE, and keeping them there brings all kinds of
problems. Just look at that list of issues and that isn't anywhere near
complete.
Moving them out of BASE would also allow handling conflicts between
them and a node that really lives at that place in the directory.
(Currently unsolvable in 1.7 as we can't have two op depth 0 nodes at
one local_abspath.
But even with op depth -1 we need more work to fix the other
limitations of file externals. Different repositories and file
externals in subdirs are not going to work from nodes without adding
checks EVERYWHERE.
With externals 100% in EXTERNALS that problem would be solved
everywhere and we only need some additional checks in libsvn_client
while libsvn_wc can just assume that a directory has its own children.
Bert Huijben (Cell phone) From: Greg Stein
Sent: zaterdag 14 mei 2011 14:01
To: Bert Huijben
Cc: dev_at_subversion.apache.org
Subject: Re: svn commit: r1102912 - in /subversion/trunk/subversion:
include/private/svn_wc_private.h libsvn_client/prop_commands.c
libsvn_wc/externals.c libsvn_wc/wc_db.c tests/libsvn_wc/db-test.c
On Sat, May 14, 2011 at 04:00, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: zaterdag 14 mei 2011 7:06
>> To: dev_at_subversion.apache.org
>> Subject: Re: svn commit: r1102912 - in /subversion/trunk/subversion:
>> include/private/svn_wc_private.h libsvn_client/prop_commands.c
>> libsvn_wc/externals.c libsvn_wc/wc_db.c tests/libsvn_wc/db-test.c
>>
>> On Fri, May 13, 2011 at 18:23, <rhuijben_at_apache.org> wrote:
>> > Author: rhuijben
>> > Date: Fri May 13 22:22:59 2011
>> > New Revision: 1102912
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1102912&view=rev
>> > Log:
>> > Make the svn_client_proplist3 funtion capable of reading properties from
>> > new style file externals.
>>
>> Huh? I thought file externals had NODES and ACTUAL_NODE rows?
>> Shouldn't the properties be available there? What are we doing
>> *special casing* externals like this?
>
> See the document you asked me to write: notes/wc-ng/externals
>
> They live in NODES now, but not after we bump to format 29. (They can/will
> probably survive in ACTUAL_NODES as they share the same path anyway)
>
> After we bump to format 29 file externals will be "just like normal
> externals". They won't be part of the parent working copy NODES tree. (And
> can come from different repositories; can be placed in subdirs; etc. etc.).
>
> But of course they will still share the parent wc's db and pristine store as
> they can't have their own administrative area.
I just read it, and I think that I disagree with the approach.
It now seems that we are going to have to special-check *everywhere*
to see if a node exists as a file external. Every single place we look
for a node, will now require a check to see if a file external lives
at that spot.
Special casing doesn't seem like a good approach.
Couldn't you have used a new presence value in the database to note
these? The NODES schema already allows for different repositories
(repos_id). All the data would live in NODES just like every other
item. No need to go and look in a different table (which already looks
much like NODES).
I'd rather see file externals look more like regular nodes, instead of
some ephemeral thing.
Cheers,
-g
Received on 2011-05-14 14:36:33 CEST