Re: [Firebird-docs] Issue DOC-129 resolved.

[Mark R. <ma...@la...>]

On 2018-02-17 11:30, Norman Dunbar wrote:
> Morning All,
> 
> it's currently 10:25 UK time. My emails to the list seem to be taking
> a few days to get to the docs list at the moment, so I've no idea if
> or when you will see this!

At the beginning of the week, SourceForge moved datacenters, and 
something went wrong pretty badly, it should have been fixed Friday (or 
maybe yesterday), as some of my messages I sent during the week were 
delivered, but some of the messages I sent yesterday have only now shown 
up. Chances are there are still some lingering problems, or maybe 
DNS-related issues.

> I've updated the gfix manual to resolve issue DOC-129 whereby the
> sweep interval was incorrectly defined.
> 
> I've raised a pull request from my specially created branch DOC-129
> for the resolution.
> 
> While I am able to merge this fix into master, I cannot merge it into
> B_release though. I get the impression that B_Release either didn't
> come across correctly, or is too far out of date from Master as
> attempting to merge my DOC-129 branch into B_release gives lots of
> conflict errors.
> 
> $git merge DOC-129
> 
[..]
> 
> Git status gives screens and screens of new files to be added, and 9
> modified files, from the 10 files listed above, to have their
> conflicts fixed.
> 
> Listed above is fbutils_gfix.xml but it isn't listed in the git status
> output as a conflicting file. Oh joy!  It also doesn't have any
> conflict markers.
> 
> $git merge --abort cleaned up the mess from the merge.
> 
> The same happens if I experiment with merging master into B_Release
> (in my local copy of my fork - so no damage done!) Another --abort
> cleaned up there too.
> 
> Has anyone else been able to merge new documents or changes into 
> B_Release?

It looks like up to now, changes were cherry picked by manually copying 
them unto the branch, or at least, most commits on B_Release seem to 
copy a specific state onto release, without retaining history from 
master. This probably explains why merging a branch from master onto 
B_Release doesn't work.

I'm not sure if there is an easy way to fix this with git in a way that 
matches with how B_Release is used. Maybe Paul or Helen could describe 
the logical steps how B_Release is supposed to be used, and we can then 
see how we can best do that with git.

Depending on the exact needs, it might take some advanced git-fu, and 
the simplest solution may turn out to be to just copy the latest state 
and commit that to B_Release, without merging the specific file-history 
on the branch.

Mark