> -----Original Message-----
> From: Neels J Hofmeyr [mailto:neels_at_elego.de]
> Sent: woensdag 5 mei 2010 11:37
> To: dev_at_subversion.apache.org; Julian Foad; Stefan Sperling; Stephen
> Butler
> Subject: another hole in tree-conflicts! -- was: Re: svn commit:
> r940111 - in /subversion/trunk/subversion:
> include/private/svn_wc_private.h include/svn_wc.h libsvn_wc/node.c
> libsvn_wc/status.c svn/cl.h svn/status-cmd.c svn/status.c
>
> On 05/03/2010 10:25 PM, Daniel Näslund wrote:
> > On Mon, May 03, 2010 at 03:07:49PM +0200, Neels J Hofmeyr wrote:
> [...]
> >>> stat->lock_creation_date = 0;
> >>> + stat->conflicted = (tree_conflict != NULL);
> >>
> >> I don't understand -- what about prop and text conflicts? Below,
> >> ->conflicted stands for all three of them.
> >> (If this is correct, I guess it needs a comment)
> >
> > Added a comment in r940600. AFAIK, the only scenario where we can get
> a
> > conflict on an unversioned node is for an incoming delete to a
> locally
> > deleted path. (It will be troublesome to fit that case into the idea
> of
> > storing tree conflict info on the node instead of its parent).
>
> ah, ok, that makes sense. Shouldn't be trouble to store such tree-
> conflict
> in the ng-ACTUAL tree? ...but, thinking aloud a little:
>
> The entry can't be NULL for a schedule-deleted node (asked for with
> show_hidden == TRUE). Analogously, the wc-ng tables do have both ng-
> BASE and
> ng-WORKING nodes for a locally deleted path.
This is the case where a node was deleted locally (schedule delete) and
deleted remotely.
After the update we couldn't leave it schedule delete as the entry was
removed from the repository, so the complete node was removed in 1.6 and a
tree conflict recorded in the parent *entry*.
(All cases where we have a node would fall through a different codepath in
the status walk)
We discussed this scenario a few weeks ago on irc, and there are two ways to
recording this in WC-NG:
1. Allow an ACTUAL_NODE record for nodes without BASE_NODE and WORKING_NODE
2. Keep a NOT-PRESENT BASE_NODE record for this case
I recommended option 2, as it doesn't introduce another status just for
recording this conflict type which we would have to check everywhere.
(Adding another status would require every loop over the result of
svn_wc__db_read_children() to check for this status).
> So, if there is no metadata in the WC on the node, there can't be *any*
> (tree-)conflict on it! Right? Let's see:
>
> Another case: obstructed; there is no metadata in the WC, but a
> file/folder
> sits at a path. Say update wants to put something at that path: it'll
> create
> a base node (above theory holds -- TC needs to have metadata).
In WC-1.0 we record this on the parent, without an entry.
In WC-NG we can create the node, but with an 'obstructed' conflict on it.
(So we can allow the 'svn update to continue')
The rest of your mail talks about how merge handles this conflict, which is
a less interesting case for the wc-ng work where I'm looking at as it is a
client feature. (But it might require recording a conflict on a not-present
node anyway)
Bert
Received on 2010-05-05 12:49:51 CEST