-----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.
>> > 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.
Ah, so it does. I don't remember how much we talked about it when
writing the spec, but I actually like the reverse better. Doesn't
matter too much, though.
>> 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.
Thanks for the heads up.
> 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.
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'll brainstorm about these issues and try to get a workable solution
sometime next week.
- -Hyrum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGYiHfCwOubk4kUXwRAvxWAJ4ziewjXos/3CyK7Vt3U4C/hylwBgCfeOS3
VCT+l0j75/8khfz5HApGMn0=
=E7UN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 3 04:02:47 2007