You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2008/07/21 22:24:54 UTC
Reverse merges and log -g
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?
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?
A concrete example can be found here:
http://subversion.tigris.org/issues/show_bug.cgi?id=3235#desc5
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reverse merges and log -g
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Jul 22, 2008 at 10:04 AM, Paul Burba <pt...@gmail.com> wrote:
> 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).
http://subversion.tigris.org/issues/show_bug.cgi?id=3235#desc8
^^^
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reverse merges and log -g
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Jul 21, 2008 at 6:51 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jul 21, 2008 at 6:24 PM, Paul Burba <pt...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reverse merges and log -g
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jul 21, 2008 at 6:24 PM, Paul Burba <pt...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org