Re: branch tree-conflicts-notify

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.

Steve, Julian, I must admit I don't know how to deal with our concurrency.
Do you have some guidance for me?

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?

Well, by now it's too late to start something proper. Sigh. Until tomorrow,
then.

~Neels

-- 
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696  mobile: +49 177 2345869  fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194