Re: New merge-sensitive log feature

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.

> > Second problem is that r10 comes from r11. So its message should say:
> >
> > Result of a merge from: r11, r13
>
> (Actually, I think it should be r13, r11)

The spec has it the other way.

> The current implementation is checking for merge children on the current
> path, not the path which was merged from. r10 was merged into trunk in
> r13, but it was also merged into branches/a in r11. I'll need to look
> at how to retrieve that information, and look at the merged revisions in
> the context of their original paths.
>
> > Final problem is that I believe there was also an r7 that should have
> > shown in the history from r11.
>
> I'm using the updated dumpfile (where r7 is blocked). Which revision is
> this for the new diagram?

In the new diagram, everything after r7 is just bumped up one, because
I added an r8 that blocks r7. This also means there is only r10 (r11
in the new dumpfile). So it might be worthwhile to hang on to the
older dumpfile.

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.

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