On 6/2/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
this.
> 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.
--
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 Sun Jun 3 15:15:57 2007