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? Ideally it would show it
reverse-merged 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.
> 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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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 00:52:07 CEST