On 6/6/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> Mark Phippard wrote:
> > On 6/6/07, Hyrum K. Wright <hyrum_wright@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
Received on Wed Jun 6 19:03:30 2007