[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Tree conflicts - revert and resolve per victim

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 06 Nov 2008 03:13:22 +0000

This time with attachment...

On Wed, 2008-11-05 at 23:24 +0000, Julian Foad wrote:
> On Wed, 2008-11-05 at 21:18 +0100, Stephen Butler wrote:
> > Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> >
> > >
> > > Yes, I am. I'm implementing an augmented variant of walk_entries now,
> > > and then I'll make "resolve" and "revert" and "info" and "status" use
> > > it.

Here's my patch for this at the end of today. Rather than "rev"
svn_wc_walk_entries3() to add an extra switch, I've chosen to implement
it as an additional API that behaves almost the same as
svn_wc_walk_entries3() but also visits the unversioned tree conflict
victims. Internally it uses svn_wc_walk_entries3() to walk versioned
entries, and within each visited versioned dir it scans for any
unversioned victims and makes additional calls to the callback.

If you'd like to comment on the approach, that would be great.

To test it, I'm just dropping it in as a replacement for the
svn_wc_walk_entries3() call in svn_wc_resolve4(), aiming for no change
in functionality. The only difference is the callback will now receive
(a) unversioned paths with a null entry (this is the whole point), and
(b) entries that are in a "deleted" or "missing" or "schedule-delete"
state, which is an intentional side effect. But I'm getting an extra
warning in the output of a "resolved" command in tree_conflict_tests 13,
for example:

[[[
CMD: svn resolved -R branch2/dP [...]
Resolved conflicted state of 'branch2/dP'
### Deleted: resolve_f_e_cb('branch2/dP/D')
svn: warning: Directory 'branch2/dP/D' is missing
]]]

I haven't investigated what causes this output yet. I'm just posting
this so you can look if you're working while I'm asleep (Neels!).

- Julian

> > That's interesting. I hadn't thought that status could be done
> > using walk_entries, but if walk_entries is augmented for nonexistent
> > items, then status might as well use callbacks like the other
> > commands.
>
> Well, I haven't actually checked that "status" doesn't do special things
> that would make it impossible. It does do special things like report
> status of unversioned items. I'll see when I get to it whether it makes
> sense to use a generic (or fairly generic but somewhat more
> specialised!) walker.
>
> Actually I probably won't even try to touch it in this round of work. It
> works as it is. It can be tidied up at some unknown time in the future.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org

Received on 2008-11-06 04:13:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.