[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Cherry picking merge sensitive logs

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-06-06 19:03:10 CEST

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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.