Stephen Butler wrote:
> Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
>
>> Hi tree-conflicts folks,
>>
>> merge notification is starting to look really nice.
>>
>> It is only implemented for the repos-diff editor in repos_diff.c, not for
>> the other ones. In fact, merge only uses the repos-diff one, so it's
>> obsolete to implement tree-conflicts notification for the wc-diff editor,
>> when no-one using the wc-diff editor is ever raising a tree conflict
>> to be
>> notified with it.
>>
>> `svn status' fails to note some tree-conflicts, but that was there
>> before.
>
> To check the status of 'missing' victims, use the helper function
> svntest.actions.run_and_verify_unquiet_status().
>
>>
>> So there only is some freak output status=' U' on some tree-conflicts
>> notifications, seen in some tests that I have left failing for now,
>> and e.g.
>> in merge_tests.py 144 (tree_conflicts_on_merge_local_ci_5_1). These
>> will go
>> away as soon as I implement sbutler's suggestion to not use a flag in
>> notify_t, but a new notify_action enum field for tree-conflicts
>> notification. I'm intending to do that on trunk because it also
>> affects the
>> update/switch code.
>
> The ' U', 'D ', etc. appear in the output because we're not yet
> skipping tree conflict victims (or their descendants).
No, for merge that's not true. It's because I'm sending
svn_wc_notify_update_update actions out because I thought that would lead to
an empty column, as it does sometimes... didn't really understand why.
Anyway, if we use a separate switch-case for displaying tree-conflicts, all
of this will entirely go away, because we only ever print a " C " before
the path. But I'm slightly worried because some places seem to use this
notify action thingy to determine their control flow, say to know which
action was carried out and what to do about it. If we introduce a new one, a
lot of logic might have to be reviewed/kept from breaking. We'll encounter
that soon enough, if I'm right.
>
>>
>> Can you guys find issues that would prevent merging tc-merge-notify
>> back to
>> trunk now?
>
> No, I think it's up to par with the update code now. Merge away!
>
>>
>> (Oh, and meta about merging: stsp told me once to use `merge
>> --reintegrate',
>> but I've read somewhere that there are problems with that and one should
>> rather use two-URL merge. Steve, which commands did you use to merge that
>> other branch back to trunk? Did you copy-paste the commit logs over,
>> and how?)
>
> I ran the usual
>
> svn merge $trunk
So this is run being in a working copy of the branch?
>
> to update the branch, and noted the highest revnum on trunk. Then
> to do the actual merge, I ran the 2-url merge
>
> svn merge $trunk@$revnum $branch
Uh, so... ah... this is done in a trunk working copy. Right?
>
> because there's mergeinfo on subtrees, which --reintegrate can't
> (yet) accept. The commit message was perhaps overkill. I put most
> of it together by copy-paste from the branch log. I generally
> write the log message in advance, then use 'svn ci -F'. Which
> gives other people a chance to commit to trunk in the meantime,
> which is why I specified the trunk revnum in the final merge cmd,
> on a tip from hwright.
Wow, that was a lot of information across another, but in the end I
understood. :)
So I don't repeat the log message, because doing so would be overkill? How
would one be able to retrieve this log message if I only had `svn ci -m
"Merging branch foo to trunk."'?
But I guess it's good to give sort of a final log message that has no open
things dangling which are closed again in some later commit...
~Neels
Received on 2008-11-01 02:23:01 CET