On Wed, Feb 23, 2011 at 15:16, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Feb 23, 2011 at 08:52:18PM +0100, Bert Huijben wrote:
>> I think just seeing every node below a workingcopy as a node in the parent
>> working copy will make things harder instead of simpler. So I would suggest
>> moving the redefining of normal externals to 1.8. (But I still think we have
>> to fix some file external issues for 1.7).
> I understand your concerns, but I'm afraid fixing file externals isn't
> the only problem we have :(
> As explained in issue #3818, flagging a tree conflict on an external
> is broken, which is a regression from 1.6.x.
> Trying to fix that, it's easy to see that other things like status on
> conflicted externals is also broken. Basically, every caller of
> svn_wc__db_wcroot_parse_local_abspath() has potential problems with
> opening the wrong wc.db that need to be worked around.
I believe the core of this issue is the "anchor/target" problem that
was discovered and designed back in the early Subversion days.
When you refer to "foo/bar/baz", are you asking about baz itself? or
are you asking about the child in bar?
In this particular scenario, conflict data is recorded in the parent,
so the query is not just a path, but a child within a path.
As Philip seemed to imply, introducing a wc_id or wcroot isn't going
to solve the problem. You're still given an abspath. I believe the
missing piece is the intentions around that path.
> I'd rather try to fix externals properly than adding workarounds.
> It seems as if there was an assumption that externals would just
> continue to work as they did in 1.6. But at least in this one case,
> we already know that this isn't true. How likely is it that there
> are more problems lurking that our test suite isn't currently exposing?
Honestly, I would recommend getting these things working as the main
priority. We can continue to revisit later. The new datastore can
represent a lot more concepts than before (elsethread, there are
discussions about switch vs externals and multi-repos... the new db
can have every item from a different repos; we just don't have the UI
model to present that to the user; but we could!)
> So, yes, it might be less effort to add workarounds for known-broken
> cases than changing the way externals are handled in a more fundamental way.
> Would you rather go the route of adding workarounds for now?
> I could try that, but it doesn't feel very reassuring because I'd like
> 1.7 to be a very good quality release.
Agreed, but I'm seeing this as a query issue rather than a modeling
issue. You're right that an abspath is not enough. But I think you're
looking in the wrong place (wc_id or wcroot_t) to solve the problem.
In the anchor/target design, you have several possible outcomes:
1) anchor=foo/bar, target="": we're asking about the bar subdir
2) anchor=foo, target="bar": we're asking about the file bar
3) anchor=foo, target="bar": we're asking about the subdir bar from
the parent foo
In the old adm_access model, these different types of queries were
managed by where the adm_access pointed to. In (3), you're getting the
"stub" information. In (1), the access_t pointed to the primary
information in the subdir. In (2), you're getting file information
from the parent dir's access_t.
> I also don't think that fixing file externals in the current 'design'
> (or lack of it) will be easy. So we might as well try a new design.
> We can still consider adding workarounds when the proper solution
> takes too long to mature to make the release in time.
> I'm happy to try this out on a branch first to avoid making things
> on trunk any worse than they are now.
Does the above help to focus your thoughts?
In particular, where exactly are the symptoms? Are they actually
widespread? Or can we solve some targeted cases and move along?
Received on 2011-02-28 22:42:14 CET