On Wed, Feb 23, 2011 at 12:26 PM, Stefan Sperling <stsp_at_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.foad_at_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
Received on 2011-02-23 19:47:19 CET