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

Re: New merge-sensitive log feature

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-06-03 15:15:44 CEST

On 6/2/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> Hash: SHA1
> Mark Phippard wrote:
> > On 6/2/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> >
> >> Ordering should be fixed now. Because ordering is determined by the way
> >> the revision range is given on the command line ('svn log -r12:15' vs.
> >> 'svn log -r15:12'), we don't have a way to say 'svn log -g -r13', but
> >> reverse the order of the merged revisions. This is just an observation;
> >> I don't think we really need to do anything about it at this point.
> >
> > I was going from the spec. I thought we had talked about this and
> > decided it should show the merged revisions in descending order.
> We did. Should merged revisions always be in descending order, or
> should they be in ascending order if the top level revisions are in
> ascending order? I'm inclined to go with the second method.

I guess as long as it uses descending order when only a single
revision is specified.

> > With the new dumpfile this is the relevant command:
> >
> > svn log -g -r14 $REPOS/trunk
> >
> > question. Why does this command give such different results:
> >
> > svn log -g -r14 $REPOS
> >
> > Seems like it really makes it go crazy.
> Currently, there isn't a whole lot of path-based filtering going on with
> the merged revisions. If the mergeinfo has something like '/trunk:1-9',
> you'll get all nine revisions, 1-9, as child revisions. And since every
> copy starts out with something like '/copysource:1-rev_before_copy', we
> end up pulling back *a lot* of data. That data will need to be
> filtered, not based upon the destination path, but upon the merge source
> path.

But my understanding was that it was not going to look at the property
at that revision, it was going to look at the *change* to the property
at that revision. Basically, to determine which of the revisions were
merged at that specific revision. It does not seem like it is doing

> Another reason for the large volume of data, is that by running the
> command on the root of the repository, you're going to get multiple
> copies of some log messages, both the original message, as well as the
> copies of the message pulled in as the result of a merge. (See
> http://svn.haxx.se/dev/archive-2007-05/0446.shtml for a previous mail on
> the issue.) This is exacerbated by the fact that we're already pulling
> in extra revisions already due to the first problem.

I remember that message. In the scenario in that message it made
sense. In this case, it seems like the problem lies in the way it is
processing the merge history.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 3 15:15:57 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.