On Fri, 2008-10-24 at 04:05 +0200, Neels J. Hofmeyr wrote:
>
> Julian Foad wrote:
> > On Fri, 2008-10-24 at 02:58 +0200, Neels J. Hofmeyr wrote:
> >> Hey guys,
> >>
> >> I'm quite glad that we're all moving in the same direction, but by now I'm
> >> thoroughly confused as to what is being done by whom, and what I should be
> >> doing next.
> >>
> >> I updated my branch wc but don't see most of the changes you talked about.
> >> Are you committing on trunk? Steve, I see you updated the branch to trunk.
> >> Are you trying to confuse me? ;)
> >
> > I'm working on trunk. I'm regarding the "tree-conflicts-notify" branch
> > as yours alone.
> >
> >> Maybe it would be good if we keep the others updated on what we were doing,
> >> as in post unfinished patches so that we don't do the exact same things in
> >> parallel. Btw, have you guys finished the other stuff you took?
> >
> > OK, here (attached) is the "skip when conflicts occur during update"
> > patch that I'm working on.
> >
> >> So, I'll take a look at merge notification, then. I'm afraid to change
> >> either of svn_wc_conflicted_p2() or update notification, because I fear you
> >> guys have patches floating for it already.
> >
> > I need an updated (per-victim) version of svn_wc_conflicted_p2(). I keep
> > starting to do it, but then stop because I don't fully understand how
> > the current callers would need to change. Maybe we can keep the current
> > version (or the previous version "svn_wc_conflicted_p()") and just
> > introduce the new version alongside it.
> >
> > My patch attached includes a local function "conflicted_p3()" that does
> > pretty much what I want the new public function to do.
> >
> > This patch also includes returning the new conflict (if any) from the
> > function check_tree_conflict, so that the calling code can generate its
> > notification and skip further edits. I believe you needed that. How
> > about you commit that part of my patch to trunk - or, if you prefer, I
> > will in the morning - with all callers just passing NULL for that output
> > parameter.
> >
> >
> >> Am I being cranky? ;)
> >
> > No, you're right that it's getting confusing. I'm feeling it too. I
> > don't know whether to just commit some partial updates or if that would
> > get in your way.
> >
> > One thing I was about to commit was removing the per-parent
> > notifications from "merge". Here's a patch for that as well. It seems a
> > bit negative to just delete that notification without adding per-victim,
> > but might be a useful start. Again, feel free to commit if you like.
> >
> > Have a good session tonight.
> >
> > - Julian
>
> So, there we have it: we're already doing overlapping stuff. For example,
> I've also added a return parameter to check_tree_conflict() on the branch
> some days ago. I see you've added stuff entirely differently.
Urgh. I've just committed the "check_tree_conflict() returns the
conflict" part of my patch, thinking that would be useful for you too. I
had forgotten, since seeing your branch patch a day or two ago, that
you'd done something similar but different. I only did that tonight in
order to get somewhere with skipping, and I only did "skipping" tonight
because it got mentioned today and I thought it was time I went back to
it.
But I see that skipping in update is very closely involved with sending
notifications, which is what you're doing. So I'll try to let you
continue without me doing too much that overlaps. But I might still
commit small incremental improvements. I hope that won't be a problem.
I'll go back to "merge --into-conflicted" tomorrow. I've started coding
(the easy bit - passing a flag along to the callbacks) but next I need
to write a test or two for it, to have a scenario in which to try it
out.
> Steve, Julian, I must admit I don't know how to deal with our concurrency.
> Do you have some guidance for me?
Mail exchanges like this one. Committing frequently.
> We're currently changing the signatures of the same functions. Not good.
> Should I rather go back to the diff-repos-wc branch (dirs_same_p) for a few
> days and then come back and merge tree-conflicts-notify into what you've
> done until then, if at all necessary?
No, I'd like it if you could carry on with tree-conflicts-notify. But if
that's difficult because the structure of the code isn't good (such as
where it's supposed to check for existing conflicts and then check
whether it's causing a new tree conflict, but doesn't do it in that
order in all cases), then maybe what I'm showing in
"skip-inside-conflicts-3.patch" will be useful.
Don't worry about committing something that might get in my way: if you
commit something that's an improvement, I'll gladly merge it into
whatever work I have in progress.
> Well, by now it's too late to start something proper. Sigh. Until tomorrow,
> then.
Have a good sleep instead, perhaps. Good night,
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-24 04:40:01 CEST