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@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 <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: zaterdag 14 mei 2011 7:06 >> To: dev@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, <rhuij...@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
