Re: [lmi] Generating pages with tables in the new PDF generation code

[Vadim Zeitlin]

On Sun, 27 Aug 2017 12:23:16 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-08-17 16:13, Vadim Zeitlin wrote:
GC> [...]
GC> > get the direct-pdf-gen branch from my GitHub repository (you don't
GC> > need a GitHub account for this) and build it yourself
GC> 
GC> I'm trying to devise a high-level strategy for merging this into lmi master.

 Sorry, I should have been more clear: this is not the branch you're
supposed to merge! This branch is based on my local "tt" branch which
contains both changes not yet merged to master and some that are not ever
supposed to go into it. If you'd like to have something mergeable, let me
rebase this branch on master -- and then you would be able to merge it much
more easily.

GC> I did this:
GC> 
GC> mkdir --parents /opt/lmi/pdf/
GC> cd /opt/lmi/pdf/
GC> git clone https://github.com/vadz/lmi.git --branch direct-pdf-gen 
--single-branch
GC> cd lmi

 I know you're allergic to branches, but this is really, really not the
optimal way to do this. Instead of creating a whole new repository, just
create the branch in your existing git repository using

        % git fetch https://github.com/vadz/lmi.git direct-pdf-gen
        % git branch direct-pdf-gen FETCH_HEAD

(the first command makes the latest commit fetched by it available under
this special FETCH_HEAD name and the second one just creates a local branch
with the same name as remote one -- this is not, strictly speaking,
necessary, but as FETCH_HEAD is implicitly updated by any "git pull" you
do, it can be confusing not to give it a more permanent name).

 And once you have this branch locally, you can just do

        % git merge direct-pdf-gen

which is what I would strongly prefer, because it would keep the history of
my commits, which can be very useful when returning to this code later. But
this would create a real merge and if you absolutely want to avoid this
(although I still believe that this wouldn't have any drawbacks whatsoever
for you), you can do

        % git merge --squash direct-pdf-gen
        % git commit

which would merge all my changes as a single commit, squashing them. Again,
this loses history and would be unfortunate IMO, but if you don't want to
make a real merge, squash-merge like above is still much better than
applying the changes manually.

 Of course, if there are any conflicts, you'd still have to resolve them
manually.


 I'll skip the discussion of the various issues because none of them would
apply once I rebase this branch on master, AFAICS. Also notice that some
trivial differences, such as the branch having an older version of the file
updated in master, would be taken care of automatically by "git merge".

GC> BTW, we will still need one XSL template, 'sort_cell_subelements.xsl',
GC> and therefore I suspect that 'ledger_xsl.?pp' cannot be removed.

 This is unfortunate... Keeping the file is not a problem, of course, but
does this mean that we'd also have to keep all the code for invoking FOP
etc? Can't we really get rid of it?

GC> The reason is that one external vendor provides XML input files whose
GC> elements are not sorted, which causes XSD validation to fail.

 Sorry, I'm a bit lost here. What does sorting XML have to do with
ledger_xsl.cpp? It doesn't seem to contain any code for doing this...


 But to return to the main question, if you'd like to test merging the new
code right now, please let me know and I'll rebase my branch on master. My
own plan was to do it later, when I consider it to be really ready for the
merge -- which is not the case yet.

 Regards,
VZ