Den lör 14 aug. 2021 kl 13:21 skrev Daniel Shahaf <d...@daniel.shahaf.name>:
> Daniel Sahlberg wrote on Fri, Aug 13, 2021 at 16:55:38 +0200: > > danielsh had two comments on IRC, > > https://colabti.org/irclogger/irclogger_log/svn-dev?date=2021-08-09, > which > > I will try to address here. I'm taking the liberty of copying from the > IRC > > log to get some context. > > Thanks, and sorry for not posting them on the list as I planned to; > suffice it to say my Wednesday didn't go according to plan. > NP, that's what I thought. Hope you didn't mind I copied your questions from IRC to shortciruit one round at the mailinglist. > > Den mån 9 aug. 2021 kl 03:12 skrev Daniel Sahlberg < > > daniel.l.sahlb...@gmail.com>: > > > I'm proposing to keep the XML tree intact, but filter out the > > > information that doesn't match the search pattern. If searching for > "add > > > 1 file", the result would be as follows: > > > > > > [[[ > > > <logentry revision="12"> > > > <logentry revision="11"> > > > <logentry revision="10" reverse-merge="false"> > > > <author>dsahlberg</author> > > > <date>2021-08-08T19:29:10.860725Z</date> > > > <msg>add 1 file</msg> > > > </logentry> > > > </logentry> > > > </logentry> > > > ]]] > > > > > > > danielsh: 1. Re your "I'm proposing", how would with/without XML compare > to > > each other? Cf. site/tools/ compiling XML output into plain output. > > > > (It seems I didn't keep my test repo, but I hope the examples should be > > readable anyway). > > > > For readability, I have reformatted the XML with proper indentation: > > [[[ > > dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk_4711/subversion/svn/svn > log > > --use-merge-history --search 'merge a' > > ------------------------------------------------------------------------ > > r5 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line > > Merged via: r6 > > > > merge a to b > > ------------------------------------------------------------------------ > > dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk_4711/subversion/svn/svn > log > > --use-merge-history --search 'merge a' --xml > > <?xml version="1.0" encoding="UTF-8"?> > > <log> > > <logentry revision="6"> > > <logentry reverse-merge="false" revision="5"> > > <author>dsahlberg</author> > > <date>2021-08-09T00:31:34.969440Z</date> > > <msg>merge a to b</msg> > > </logentry> > > </logentry> > > </log> > > ]]] > > > > In plain text output the inheritance is show by the "Merged via:" line, > in > > XML is found by examining the tree. > > Okay, and what about the example above with two levels of nesting? How > does that compare? Do XML and plain output modes implement filtering > the same way (e.g., do both of them elide details of r11)? > Again, sorry for not having the original WC. This is my current test WC: a, b and c are separate folders directly under the root. The XML output has been indented for readability purposes. The examples are done with a patched svn using my second approach [[[ dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk/subversion/svn/svn log -g ------------------------------------------------------------------------ r6 | dsahlberg | 2021-08-09 02:31:35 +0200 (Mon, 09 Aug 2021) | 1 line merge b to c ------------------------------------------------------------------------ r5 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line Merged via: r6 merge a to b ------------------------------------------------------------------------ r4 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line Merged via: r6, r5 add a/foo ------------------------------------------------------------------------ r3 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line copy b to c ------------------------------------------------------------------------ r2 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line copy a to b ------------------------------------------------------------------------ r1 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line add a ------------------------------------------------------------------------ dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk/subversion/svn/svn log -g --xml <?xml version="1.0" encoding="UTF-8"?> <log> <logentry revision="6"> <author>dsahlberg</author> <date>2021-08-09T00:31:35.068294Z</date> <msg>merge b to c</msg> <logentry revision="5" reverse-merge="false"> <author>dsahlberg</author> <date>2021-08-09T00:31:34.969440Z</date> <msg>merge a to b</msg> <logentry revision="4" reverse-merge="false"> <author>dsahlberg</author> <date>2021-08-09T00:31:34.870273Z</date> <msg>add a/foo</msg> </logentry> </logentry> </logentry> <logentry revision="3"> <author>dsahlberg</author> <date>2021-08-09T00:31:34.798928Z</date> <msg>copy b to c</msg> </logentry> <logentry revision="2"> <author>dsahlberg</author> <date>2021-08-09T00:31:34.767518Z</date> <msg>copy a to b</msg> </logentry> <logentry revision="1"> <author>dsahlberg</author> <date>2021-08-09T00:31:34.725920Z</date> <msg>add a</msg> </logentry> </log> dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk/subversion/svn/svn log -g --search foo ------------------------------------------------------------------------ r4 | dsahlberg | 2021-08-09 02:31:34 +0200 (Mon, 09 Aug 2021) | 1 line Merged via: r6, r5 add a/foo ------------------------------------------------------------------------ dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk/subversion/svn/svn log -g --search foo --xml <?xml version="1.0" encoding="UTF-8"?> <log> <logentry revision="6"> <logentry revision="5"> <logentry reverse-merge="false" revision="4"> <author>dsahlberg</author> <date>2021-08-09T00:31:34.870273Z</date> <msg>add a/foo</msg> </logentry> </logentry> </logentry> </log> dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk/subversion/svn/svn log -g --search 'no' ------------------------------------------------------------------------ dsahlberg@daniel-2020:~/temp/wc/c$ ~/svn_trunk/subversion/svn/svn log -g --xml --search 'no' <?xml version="1.0" encoding="UTF-8"?> <log> </log> dsahlberg@daniel-2020:~/temp/wc/c$ ]]] Yes, they implement filtering the same way, only the revision that actually match is printed. The merge history is either emitted as part of the tree or in the Merged via: line (see log-cmd.c, lines 425 to 446, that part of the code mirrors the loop to over the merge_stack to create opening tags for all revisions !emitted). > I checked site/tools/upcoming.py. It doesn't use "-g" (which is > responsible > > for generating the recursive tree) so it expects all logentry elements to > > be children of <log>, ie, it would not consider revision 5 above. Any > tool > > that is using "-g" should already be able to traverse a tree with > logentry > > elements that are children of other logentry elements (which could be > > children of other logentry elements which ...). > > Sure, tools that don't use -g ignore nested <logentry>. No question > about that. My question was a bit different, though. In context of > your proposal: > > > > I'm proposing to keep the XML tree intact, but filter out the > > > information that doesn't match the search pattern. > > The proposal does not discuss non-XML output at all. However, the XML > and plain output are literally two different output syntaxes of the same > subcommand, so I was looking for a comment on whether the proposed > change does or does not align with the output of the same command when > «--xml» is removed. > > Specifically, I was pointing out site/tools/upcoming.py as a tool that > synthesizes plain output from XML output. Shouldn't any change to XML > or plain output retain the possibility to synthesize plain output from > XML output? It's not clear to me whether this is the case in trunk@HEAD > for «log -g», nor whether it would be the case under the proposal. > Oh, sorry, misunderstanding. Agree that the XML should output a superset of the information in plaintext. In trunk@HEAD this is not the case for the bug under discussion (where --search elide the opening tags for r6 and r5 in the example above) but it is true in the other cases. With the proposed patch it is true in all cases (well, unless there are bugs). There is one thing I'm not sure about. There is an attribute reverse-merge, it corresponds to log_entry->subtractive_merge. With --search this attribute is elided for the revisions that don't match the search pattern. This is the same for the plaintext log (it only look for it in r4 to decide to print either "Reverse merged via" or "Merged via") and the property is present in r4 so the XML is enough to synthesize the plaintext output. Is there any point in having this information also for r5? We could change the merge_stack to store this as well if needed, but I don't have a clear picture about the merge/reverse merge flow. Thanks, Daniel. > > Daniel > I hope this answers your questions! Thanks, Daniel. Daniel (Sticking to your ending of the mail. Why change a winning concept :-) /dsahlberg)
