On Wed, Feb 23, 2011 at 12:26 PM, Stefan Sperling <s...@elego.de> wrote: > On Wed, Feb 23, 2011 at 04:26:52PM +0000, Julian Foad wrote: >> Hyrum K Wright wrote: >> > On Wed, Feb 23, 2011 at 9:53 AM, Julian Foad <julian.f...@wandisco.com> >> > wrote: >> > > Stefan Sperling wrote: >> > >> So, ideally, we should decouple the >> > >> concept of a wcroot from the path. We could tie it to a wc_id instead. >> > >> This would allow us to use a single wc.db to manage several wcroots, >> > >> one for the parent working copy, and more for any externals within >> > >> this working copy. >> > >> > I've always thought we could handle it a different way: the externals >> > are just part of the same WC as the directories which contain them, >> > it's just the repos_id and/or repos_relpath which happen to point to a >> > disjoint location. In other words, externals are nothing more than >> > switched paths, save for the fact that their existence is communicable >> > to other clients via the properties (whereas "pure" switched paths are >> > single-client-only). >> > >> > Since all the plumbing for switched paths already exists, we should >> > just be able to reuse it for the externals cases. In fact, as >> > currently implemented, switch can do some *really* interesting things, >> > which Philip could probably better illuminate than me. >> > >> > In short, I don't think the answer is a set of wcroots but rather one >> > wcroot with a set of nodes (possibly pointing to various repos). >> >> +1 to that. In fact, I wrote about that idea a while back: >> >> Subject: [RFC] 'External' and 'Switched': common ground >> From: Julian Foad <julian.foad_at_wandisco.com> >> Date: Fri, 20 Aug 2010 18:54:09 +0100 >> <http://svn.haxx.se/dev/archive-2010-08/0529.shtml> >> >> There are a few intentional differences in the way external directories >> (and files) behave, compared with switched nodes, but it looks far more >> sensible to implement them that way. > > We need to preserve 1.6 semantics of how operations affect externals.
Why? People have been wanting to commit across externals and working copies for a *long* time. Putting them all in the same WC gives us this functionality for free (as well as other currently-not-atomic operations). Perserving these same limiting 1.6 semantics is something of a hard sell. > When treating externals just like switched paths, how will you make sure > that wc.db queries run within the context of one WC don't touch things > within an external WC? > > Filtering on the wc_id makes this very easy. > Having to filter on a repos URL instead, how do you avoid filtering out > switched paths which are in fact part of the parent WC and not an external? > > Or do you want to filter on the values of svn:externals within rows > returned by the query? Again, that is much harder than just filtering > on the wc_id, and requires parsing the properties to get at information > that might even been needed within SQL queries. > > If we cannot easily tell the difference between a switched path > and an external, that is bad design, IMHO, and will lead to problems > down the road just like we had with file externals in 1.6. > Let's not repeat that mistake. Externals are special and need their own, > unique, representation in our design. I submit that this may not be true. They have given us so many headaches precisely because we claim they are special. Treating externals as switched nodes will eliminate a number of these special cases. (And while I think this is a good discussion to have, I'm hopeful it doesn't lead to further delays in shipping 1.7.) -Hyrum