Daniel Sahlberg wrote on Sun, Aug 15, 2021 at 22:11:29 +0200: > 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.
Thanks for doing that. > > 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 > [[[ ⋮ > ]]] > > 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). Thanks for the verbose example. Sounds good. > > 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). *nod* > 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? Sure: provide to cmdline XML consumers data that the C API provides. It's similar to the relation between plain and XML log outputs, in that the former is a subset of the latter. subversion/svn/schema/log.rnc doesn't mention reverse-merge at all. (I was looking to see whether the attribute was declared mandatory or not.) Could adding the attribute to r5 break anything? > 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. That's a bit of a large question. Handwavingly, merging rN from /foo to /bar "adds some diff" to /bar and records that in svn:mergeinfo; thereafter, reverse-merging the same revision from the same path will reverse both of these changes. Note: if the reverse merge was committed as rM, _that_ revision can be (forward) merged to a third branch. That commit would then add /bar:M and remove /foo:N from the third branch's mergeinfo. > > 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) Well, so long as they don't ask us to do a _Two Ronnies_ skit at the next hackathon :-) Cheers, Daniel
