Menu
▾
▴
firebird-docs
|
From: Norman D. <No...@du...> - 2018-02-17 10:30:11
|
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! 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 Auto-merging src/docs/refdocs/refdocs.xml CONFLICT (content): Merge conflict in src/docs/refdocs/refdocs.xml Auto-merging src/docs/refdocs/langref/langrefupd25.xml CONFLICT (content): Merge conflict in src/docs/refdocs/langref/langrefupd25.xml Auto-merging src/docs/refdocs/langref/langrefupd21.xml CONFLICT (content): Merge conflict in src/docs/refdocs/langref/langrefupd21.xml Removing src/docs/refdocs/langref/langref25.xml Auto-merging src/docs/papers/firebird_php_linux.xml CONFLICT (content): Merge conflict in src/docs/papers/firebird_php_linux.xml Auto-merging src/docs/papers/firebird_enterprise.xml CONFLICT (content): Merge conflict in src/docs/papers/firebird_enterprise.xml Auto-merging src/docs/firebirddocs/ubuntu-setup.xml CONFLICT (content): Merge conflict in src/docs/firebirddocs/ubuntu-setup.xml Auto-merging src/docs/firebirddocs/quickstartguide-3.xml CONFLICT (add/add): Merge conflict in src/docs/firebirddocs/quickstartguide-3.xml Auto-merging src/docs/firebirddocs/quickstartguide-2.5.xml Auto-merging src/docs/firebirddocs/fbutil_isql.xml CONFLICT (content): Merge conflict in src/docs/firebirddocs/fbutil_isql.xml Auto-merging src/docs/firebirddocs/fbutil_gfix.xml CONFLICT (content): Merge conflict in src/docs/firebirddocs/fbutil_gfix.xml Auto-merging src/docs/firebirddocs/docbuilding-howto.xml CONFLICT (content): Merge conflict in src/docs/firebirddocs/docbuilding-howto.xml Removing ChangeLog Automatic merge failed; fix conflicts and then commit the result. 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? Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 |
|
From: Mark R. <ma...@la...> - 2018-02-18 19:33:25
|
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 |
|
From: Mark R. <ma...@la...> - 2018-02-18 19:43:26
|
On 2018-02-17 11:30, Norman Dunbar wrote: > 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! Specifically, your mail has been stuck for close to 32 hours somewhere inside sourceforge, see the received timestamps: Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.89) (envelope-from <fir...@li...>) id 1enTOv-0000Pk-DP; Sun, 18 Feb 2018 18:09:25 +0000 Received: from siteops-lb-1.v20.lw.sourceforge.com ([172.30.20.11] helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <No...@du...>) id 1emzkw-00099H-Vd for fir...@li...; Sat, 17 Feb 2018 10:30:10 +0000 |
|
From: Paul V. <pa...@vi...> - 2018-02-19 00:04:05
|
Hi all, [ about committing to B_Release ] > 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. And that's exactly how we're supposed to do it, even in the CVS days: Once a document reaches a publishable state (again), you copy it to B_Release, overwriting the current content (which represents the previous publishable state of that document). This way, B_Release's head always contains the most recent buildable and publishable version of every manual. Cheers, Paul |
|
From: Mark R. <ma...@la...> - 2018-02-28 07:31:34
|
On 19-2-2018 00:56, Paul Vinkenoog wrote: > Hi all, > > [ about committing to B_Release ] > >> 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. > > And that's exactly how we're supposed to do it, even in the CVS days: > > Once a document reaches a publishable state (again), you copy it to > B_Release, overwriting the current content (which represents the > previous publishable state of that document). > > This way, B_Release's head always contains the most recent buildable > and publishable version of every manual. Ok, assuming the local master is up-to-date and you are on branch B_Release, you can use git checkout master <path-of-file> Path of file is relative to your current position in the repository. This will copy the file exactly as it is on the HEAD of master, without commit history. As far as I know this would need to be done for each file individually, which may not be ideal for larger manuals. Mark -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2018-02-19 00:34:43
|
Hi Norman, > 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. I've just merged your commit. But since this is 'your own' doc, you might just as well have pushed it directly, just like in days of old, when we were using CVS and ran around in bearskin. > 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. Simply copy it over and commit/push it like we decided in 2011: >> When you're going to publish, you bluntly copy the file(s) in question >> over their counterparts in the B_Release working copy, and commit there >> (of course you also commit to HEAD). The advantage of this method is >> that now you are absolutely sure that the revision in B_Release is >> identical to the one in HEAD. You can't make subtle mistakes while >> merging, because there's no merging and tagging involved. You just >> bulldozer your way into the B_Release branch and drop your stuff there. > > I like blunt and I don't care what the cvs gurus think! ;-) This sounds > by far the method most likely to cause the least errors! I think I'll be > sticking with this option. Cheers, Paul |
|
From: Norman D. <No...@du...> - 2018-02-28 05:49:21
|
Evening All, consider the B_Release branch now up to date as far as gfix is concerned. I wasn't aware that I had write privileges on the main repository, hence why I created a fork. I'll know next time. Anyone got Sergei's email address as I need to send him my ssh key again. Thanks. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 |
|
From: Mark R. <ma...@la...> - 2018-02-28 09:31:32
|
On 20-2-2018 21:25, Norman Dunbar wrote: > Evening All, > > consider the B_Release branch now up to date as far as gfix is concerned. > > I wasn't aware that I had write privileges on the main repository, hence > why I created a fork. I'll know next time. > > Anyone got Sergei's email address as I need to send him my ssh key > again. Thanks. Sergey Mereutsa <se...@dq...> PS Interesting, it looks like SourceForge still has hickups.. your mail (and one of mine) had been stuck for 8-9 days. Mark -- Mark Rotteveel |
Thanks for helping keep SourceForge clean.
X