Cherry picking merge sensitive logs

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

The 'svn log -g' feature, as currently spec'd, only displays merged
revisions as children of a merging revision.  For example, if r14 merged
r13 and r12 from 'branches/a' to 'trunk', we only return log information
for r13 and r12 if for 'svn log -g trunk' with some range that includes r14.

This make sense, but in some ways, it would seem useful to be able to
run 'svn log -g -r13 trunk', and have the information from r13 get
returned.  After all, r13 is now part of trunk, by virtue of the merge
in r14.

So, these are my questions:
1) Is this desired behavior?

2) What is the difficulty in determining whether or not a particular
revision is part of a given path, either as a direct commit, or as the
result of a merge?  (<thinking-to-self>Wait a second, that's what
svn:mergeinfo is for.  Is that all I need?  It just seems too
easy...</thinking-to-self>)

3) How would this be displayed?  Would it be possible to easily
determine the merging revision so that the output would be consistent
with other output from 'svn log -g'?

-Hyrum

Re: Cherry picking merge sensitive logs

[Mark Phippard <ma...@gmail.com>]

On 6/6/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> Mark Phippard wrote:
> > On 6/6/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> >> The 'svn log -g' feature, as currently spec'd, only displays merged
> >> revisions as children of a merging revision.  For example, if r14 merged
> >> r13 and r12 from 'branches/a' to 'trunk', we only return log information
> >> for r13 and r12 if for 'svn log -g trunk' with some range that
> >> includes r14.
> >>
> >> This make sense, but in some ways, it would seem useful to be able to
> >> run 'svn log -g -r13 trunk', and have the information from r13 get
> >> returned.  After all, r13 is now part of trunk, by virtue of the merge
> >> in r14.
> >>
> >> So, these are my questions:
> >> 1) Is this desired behavior?
> >
> > I don't think it is desirable.
>
> I'm confused by your answer, and the the fault lies in my question.  Let
> me rephrase:
>
> 1a) Is the *current* spec desirable, or should we change it to allow
> cherry-picking?

I guess I viewed your scenario a little differently  Should svn log -r
X path return results when path was not changed in r X.  I do not
think it should, even if the -g flag is added.  I just think that
would be different than saying "here is r X for path, and oh by the
way, since you asked, here are revisions A, B, and C that were merged
at r X".

-- 
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

Re: Cherry picking merge sensitive logs

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

Mark Phippard wrote:
> On 6/6/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
>> The 'svn log -g' feature, as currently spec'd, only displays merged
>> revisions as children of a merging revision.  For example, if r14 merged
>> r13 and r12 from 'branches/a' to 'trunk', we only return log information
>> for r13 and r12 if for 'svn log -g trunk' with some range that
>> includes r14.
>>
>> This make sense, but in some ways, it would seem useful to be able to
>> run 'svn log -g -r13 trunk', and have the information from r13 get
>> returned.  After all, r13 is now part of trunk, by virtue of the merge
>> in r14.
>>
>> So, these are my questions:
>> 1) Is this desired behavior?
> 
> I don't think it is desirable.

I'm confused by your answer, and the the fault lies in my question.  Let
me rephrase:

1a) Is the *current* spec desirable, or should we change it to allow
cherry-picking?

-Hyrum

Re: Cherry picking merge sensitive logs

[Mark Phippard <ma...@gmail.com>]

On 6/6/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> The 'svn log -g' feature, as currently spec'd, only displays merged
> revisions as children of a merging revision.  For example, if r14 merged
> r13 and r12 from 'branches/a' to 'trunk', we only return log information
> for r13 and r12 if for 'svn log -g trunk' with some range that includes r14.
>
> This make sense, but in some ways, it would seem useful to be able to
> run 'svn log -g -r13 trunk', and have the information from r13 get
> returned.  After all, r13 is now part of trunk, by virtue of the merge
> in r14.
>
> So, these are my questions:
> 1) Is this desired behavior?

I don't think it is desirable.

-- 
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