Daniel Sahlberg wrote on Wed, Aug 18, 2021 at 07:54:47 +0200:
> Den tis 17 aug. 2021 kl 05:36 skrev Daniel Shahaf <d...@daniel.shahaf.name>:
>
> > 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>:
> > > > 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.)
> >
>
> So, let's add it. Since it is not present in the case where there are no
> merges, it should be optional. See if I got this right (first time touching
> XML RELAX NG schemas):
> [[[
> Index: subversion/svn/schema/log.rnc
> ===================================================================
> --- subversion/svn/schema/log.rnc (revision 1892122)
> +++ subversion/svn/schema/log.rnc (working copy)
> @@ -28,7 +28,8 @@
> logentry =
> element logentry { attlist.logentry, author?, date?, paths?, msg?,
> revprops?, logentry* }
> attlist.logentry &=
> - attribute revision { revnum.type }
> + attribute revision { revnum.type },
> + attribute reverse-merge { "true" | "false" }?
I don't know. I've not worked with .rnc schemata before. Do you have
a more specific question about this change? Any particular aspect of it
you aren't sure about?
> ## Changed paths information.
> paths = element paths { path+ }
> ]]]
>
>
> >
> > Could adding the attribute to r5 break anything?
> >
>
> The attribute is already known (to those observing the existing output of
> -g). Most XML parsers (that I have worked with) ignore unknown or
> unexpected attributes so I think it wouldn't be a problem - in any case
> they will have trouble with r4 (see my example two mails upthread) where it
> WILL be present.
>
> I also don't think it will be a problem NOT to have it, since it doesn't
> exist in non -g outputs.
>
> The larger question is "do we want it?". In other words: Is it a property
> of r5 (which was filtered out, so it should be filtered out as well) or is
> it a property necessary to reconstruct the path to r4.
I think we should include it, because:
- The API provides it. The CLI be to the API as the plain log output is
to the XML output.
- It adds information: absence does not imply the value would be "true",
nor that it would be "false".
> > > 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.
> >
>
> Out of time right now but I intend to come back to this and try to
> construct a tree with this sequence.
*nod*
> > Well, so long as they don't ask us to do a _Two Ronnies_ skit at the
> > next hackathon :-)
> >
>
> Someone volonteer to host a new hackathon and I would probably consider
> doing a Two Ronnies skit.
> (Darn, just realised I might have banned myself for life).
Hey, don't jump to conclusions. Knowing our fellow developers, they'll
set the invariant lower, at "Daniel attends nand Daniel attends".
Cheers,
Daniel
> Kind regards,
> Daniel
