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" }?
## 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.
> > 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.
> 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).
Kind regards,
Daniel
