On Mon, Jul 21, 2008 at 6:51 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Mon, Jul 21, 2008 at 6:24 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> While looking at the recent fix for issue #3235 I entered some notes
>> in the issue regarding what I thought was a problem with log -g. But
>> now I'm not so sure...
>>
>> ...the question is:
>>
>> Should log -g follow reverse merges?
>>
>> For example, say we:
>>
>> 1) Merge -r3:5 from trunk to branch and commit as r6.
>>
>> svn log -g -r6 branch includes r3 and r5 in its output, that seems
>> right. But what if we then:
>>
>> 2) Reverse merge -c-5 from 'branch' to 'trunk' and commit it as r7.
>>
>> Should svn log -g -r7 branch (or any of it's child paths) show r5?
>
> You mean should r7 show it merged r5?
Yes, that's what I was asking. But after sleeping on it I realize
that "of course it should". Sorry, a bit late to thinking about log
-g in depth.
> Ideally it would show it reverse-merged r5.
Agreed, some way of flagging these would be nice. Maybe the "Merged
via: r5" language for merged revisions could be "Reverse-merged via:
r5"?
> I do think when it gets to r6 it should still show
> that was a merge of r3 and r5. Not sure if you are asking about that.
No, I totally agree that log -g of r6 should show r4 and r5.
>> 1.5.0 and trunk do show r5 when the log target is one of branch's
>> children, but not when the target is branch itself (obviously one or
>> the other is wrong it's just that I'm not sure which!). Since
>> 'branch' has effectively never had r5 merged to it at this point,
>> isn't mentioning r5 misleading?
>
> I am virtually certain there was no attempt made to not show r5 in
> this case. Where it does not is probably just some bug in the logic
> of determining a merge. I noticed this during the pre-releases. I
> think the ideal would be to somehow indicate the revision was reverse
> merged, short of that, I actually think it is better to mention it
> than not mention it so that the revision (7 in your example) is still
> identified as a merge.
Ok, I'm convinced that showing reverse merges is the right thing to
do. Putting aside the question of whether revisions resulting from
reverse merges should be flagged, there is still the problem of some
reverse merges not showing up (see
http://subversion.tigris.org/issues/show_bug.cgi?id=3235#desc7).
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-22 16:04:55 CEST