Menu
▾
▴
firebird-docs
|
From: Paul V. <pa...@vi...> - 2017-10-08 20:13:02
|
To all committers: SourceForge have announced that they plan to terminate CVS read-write support on November 30. The CVS manual module will still be available after that for checkouts and updates, but not for commits. That means that we have around 7 weeks to implement another solution. Options are: - convert the module to SVN on SourceForge; - convert the module to Git on SourceForge; - convert the module to <whatever> and host it somewhere else. Given the nature, and low traffic, of our module, I'm inclined to go for in-place conversion to SVN. But the other options are also feasible. Any opinions? Cheers, Paul Vinkenoog |
|
From: Jiří Č. <ji...@ci...> - 2017-10-09 05:27:15
|
Convert to Git and put it under FirebirdSQL organization on GitHub for extra visibility. It might even help with contributions. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ |
|
From: Alexey K. <ak...@ib...> - 2017-10-09 06:08:36
|
On 09.10.2017 8:27, Jiří Činčura wrote: > Convert to Git and put it under FirebirdSQL organization on GitHub for > extra visibility. It might even help with contributions. > +1 Regards, Alexey |
|
From: Norman D. <No...@du...> - 2017-10-09 07:28:09
|
I agree with the git option too. Cheers, Norm. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
From: Mark R. <ma...@la...> - 2017-10-09 07:13:16
|
On 8-10-2017 21:03, Paul Vinkenoog wrote: > To all committers: > > SourceForge have announced that they plan to terminate CVS read-write > support on November 30. > > The CVS manual module will still be available after that for checkouts > and updates, but not for commits. > > That means that we have around 7 weeks to implement another solution. > > Options are: > > - convert the module to SVN on SourceForge; > - convert the module to Git on SourceForge; > - convert the module to <whatever> and host it somewhere else. > > Given the nature, and low traffic, of our module, I'm inclined to > go for in-place conversion to SVN. But the other options are also > feasible. > > Any opinions? I think it would be preferable if the documentation project would move to GitHub (https://github.com/FirebirdSQL), where the main project resides. If complexity of git is a problem: GitHub also allows subversion access to a git repository: https://help.github.com/articles/support-for-subversion-clients/ I am willing to spend some time to test and perform the conversion of the manual module to Git (and GitHub), so the commit history is preserved. If the consensus is for subversion, I can do that as well. Just a heads up: This is also being discussed in firebird-admin. Mark -- Mark Rotteveel |
|
From: Mark R. <ma...@la...> - 2017-10-11 09:44:26
|
On 9-10-2017 09:13, Mark Rotteveel wrote: > I think it would be preferable if the documentation project would move > to GitHub (https://github.com/FirebirdSQL), where the main project resides. > > If complexity of git is a problem: GitHub also allows subversion access > to a git repository: > https://help.github.com/articles/support-for-subversion-clients/ > > I am willing to spend some time to test and perform the conversion of > the manual module to Git (and GitHub), so the commit history is > preserved. If the consensus is for subversion, I can do that as well. I'll be doing a test conversion of the ODBC repository this weekend. If it is quick to do, I'll also do a test conversion of the docs repository. Mark -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2017-10-11 11:59:22
|
Hi all, Three people - one of them a committer - have expressed their preference for moving to GitHub. I have no problem with that, but I would also like to hear Helen's opinion, as she is the heaviest user of the manual module. Cheers, Paul Vinkenoog |
|
From: Paul V. <pa...@vi...> - 2017-10-11 12:02:49
|
Mark Rotteveel wrote: >> I am willing to spend some time to test and perform the conversion of >> the manual module to Git (and GitHub), so the commit history is >> preserved. If the consensus is for subversion, I can do that as well. > > I'll be doing a test conversion of the ODBC repository this weekend. If > it is quick to do, I'll also do a test conversion of the docs repository. Thanks, that would be most interesting. I'm especially curious about the preservation of the history, including branches (not that we have many of those). Cheers, Paul Vinkenoog |
|
From: Mark R. <ma...@la...> - 2017-10-11 12:15:57
|
On 11-10-2017 14:02, Paul Vinkenoog wrote: > Mark Rotteveel wrote: > >>> I am willing to spend some time to test and perform the conversion of >>> the manual module to Git (and GitHub), so the commit history is >>> preserved. If the consensus is for subversion, I can do that as well. >> >> I'll be doing a test conversion of the ODBC repository this weekend. If >> it is quick to do, I'll also do a test conversion of the docs repository. > > Thanks, that would be most interesting. I'm especially curious about > the preservation of the history, including branches (not that we have > many of those). That should work fine. I previously did a conversion of the client-java module from CVS to Subversion (and then later to git), with preservation of all history. If direct conversion runs into problem, I'll first convert to subversion, and then use the GitHub import tool like I did for Jaybird ;) Mark -- Mark Rotteveel |
|
From: Mark R. <ma...@la...> - 2017-10-11 12:08:35
|
On 11-10-2017 13:59, Paul Vinkenoog wrote: > Hi all, > > Three people - one of them a committer - have expressed their preference > for moving to GitHub. Two committers, although it has been a while (3 years AFAICT), I have committed to the manual module. > I have no problem with that, but I would also like to hear Helen's opinion, > as she is the heaviest user of the manual module. Sure, I will just do a test conversion for now to work out the kinks (if any), and document the necessary steps. Mark -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2017-10-11 12:48:20
|
Mark Rotteveel wrote: >> Three people - one of them a committer - have expressed their preference >> for moving to GitHub. > > Two committers, although it has been a while (3 years AFAICT), I have > committed to the manual module. I know, I counted back to January 2016. Earlier committers are has-beens ;-) Cheers, Paul |
|
From: Mark R. <ma...@la...> - 2017-10-14 16:43:46
|
I have made an initial conversion to git, the results are on https://github.com/mrotteveel/test-firebird-documentation (hosted on my account while doing testing) There are some differences when comparing against a CVS checkout (with TortoiseCVS): - A branch 'd_jencks' from near the start of the project has surfaced, I'll see if I can filter that one out or otherwise I'll delete it manually (IIRC this was a cross-module branch, I recall seeing it in Jaybird as well when I migrated from CVS to Subversion a few years ago) - Tags previously not visible in CVS have shown up (not really important) - Git has no keyword expansion, and in the current config of the conversion, things like $Id$ are collapsed (instead of - as an example - "$Id: formal.xsl,v 1.1 2007/04/15 16:33:16 paulvink Exp $"); I think I'll leave that as is, on master there is only a single occurrence (in src\docs\xsl\fo\formal.xsl) - Four files have a difference in line-endings (LF in git vs CRLF in CVS) while other files do have the same line-endings. It is normal that git stores line-endings in text files as LF, but my git config on Windows should normally change these back to CRLF on checkout. I'll see if I can tweak that, but attempts to fix similar problems in the OdbcJdbc module conversion where unsuccessful. Note that this difference in line-endings shouldn't be a real problem, but might cause a lot of irrelevant whitespace changes when committing changes to these files. I'll be performing more test conversion tomorrow (in numbered variants of this repository). If you have time to test and compare, I'd be happy to get your feedback. Mark -- Mark Rotteveel |
|
From: Mark R. <ma...@la...> - 2017-10-15 14:41:51
|
I have made a few more test runs, the end result is in https://github.com/mrotteveel/test-firebird-documentation-3 I think this would be the final run. Difference against yesterday: - Removed the d_jencks branch - Added a .gitignore to ignore build files - Added a .gitattributes with sane defaults for the project As to the problem with line-endings, yesterday I looked cross-eyed, and the problem with the four files were actual in reverse, they had LF in CVS and CRLF in git. I have managed to normalize these files so future updates to these files should not cause a large-scale whitespace update. Mark -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2017-10-15 23:06:59
|
Hi Mark, > I have made a few more test runs, the end result is in > https://github.com/mrotteveel/test-firebird-documentation-3 > > I think this would be the final run. > > Difference against yesterday: > > - Removed the d_jencks branch > - Added a .gitignore to ignore build files > - Added a .gitattributes with sane defaults for the project > > As to the problem with line-endings, yesterday I looked cross-eyed, and > the problem with the four files were actual in reverse, they had LF in > CVS and CRLF in git. I have managed to normalize these files so future > updates to these files should not cause a large-scale whitespace update. Thanks for all your efforts! I'll have a look at it today (Monday) or at the latest tomorrow. Cheers, Paul |
|
From: Helen B. <he...@ii...> - 2017-10-16 21:28:00
|
Thursday, October 12, 2017, 12:59:11 AM, Paul V. wrote: > Hi all, > Three people - one of them a committer - have expressed their preference > for moving to GitHub. > I have no problem with that, but I would also like to hear Helen's opinion, > as she is the heaviest user of the manual module. I guess I have to say (to quote my ex-Navy husband) "that's life in a blue suit." My preference would have been to convert to SVN and leave the repository on Sourceforge - don't fix what aint broke. But Github seems to dominate our (project) lives these days. Currently, with the CVS and SVN clients I use - necessarily on Windows, since our doc app is Windows-based - I can commit, check out, etc. from a right click on the /manual/ subdir, or any subdir beneath it. Given that I'm committing to multiple projects, this is a blessing that I will miss badly. After all these months with the core project on GitHub, I have yet to succeed in downloading the repository AT ALL to access the readme files in the core tree for use in the release notes. I have to rely on Dmitry sending me a link, from which I can view a file and copy/paste it into my local resource directory for that version. As for code control, I currently keep two copies of the /manual/ branch: one for working on and the other which I sync with the working one before committing. I have no idea how I will manage with the Github thing. Any docs I have read so far (and I have not tried in recent months) assumes that one is working on the entire source code tree. I do NOT want to keep a current copy of the entire tree. To consult core source code, it is simple for me to find what I want in the repository and copy/paste it, since I never commit changes to that code. I guess I just have to work something out. This is about the worst week Mark could have picked, from my POV, as I'm already burning the midnight oil on other project infrastructure problems and TRYING (in conjunction with Denis Simonov) to sort out the Ringlish translation of the FB Developer's Guide. Note that Denis will have to be "in" on any changes as, this time around, he is planning to convert the Word text to DocBook himself and (presumably) commit the DocBook source once he has built it successfully. Amongst other things, he has quite a number of screenshots there which, of course, are binary files. I have no idea how GH deals with image files but I guess we are going to find out soon enough. I can't walk him through it myself, since I am clueless about how it's going to work. Helen |
|
From: Kjell R. <kje...@ma...> - 2017-10-17 09:23:18
|
Helen Borrie wrote: > Currently, with the CVS and SVN clients I use - necessarily on > Windows, since our doc app is Windows-based - I can commit, check out, > etc. from a right click on the /manual/ subdir, or any subdir beneath > it. Given that I'm committing to multiple projects, this is a > blessing that I will miss badly. For Windows, I'd recommend TortoiseGit: https://tortoisegit.org/ It's a GUI for Git that's implemented as a Windows Explorer integration, and you do commits and push/pull from the right-click menu. Very much like TortoiseSVN. Regards, Kjell Rilbe Telefon: 08-761 06 55 Mobil: 0733-44 24 64 Marknadsinformation i Sverige AB Ulvsundavägen 106C 168 67 Bromma www.marknadsinformation.se 08-514 905 90 |
|
From: Helen B. <he...@ii...> - 2017-10-17 04:45:32
|
Hello Mark, Monday, October 16, 2017, 3:41:43 AM, you wrote: > I have made a few more test runs, the end result is in > https://github.com/mrotteveel/test-firebird-documentation-3 > I think this would be the final run. > Difference against yesterday: > - Removed the d_jencks branch > - Added a .gitignore to ignore build files > - Added a .gitattributes with sane defaults for the project > As to the problem with line-endings, yesterday I looked cross-eyed, and > the problem with the four files were actual in reverse, they had LF in > CVS and CRLF in git. I have managed to normalize these files so future > updates to these files should not cause a large-scale whitespace update. I downloaded the zip from your repository and looked at a few of the .docbook files from the v.3.0.2 release notes with the editor I use for creating and updating them. They look OK to me. The ReadMe file in the base directory has messed-up line-endings, though. I guess we'll need to test what happens when one of the (currently good) source files gets updated. We definitely cannot do with extraneous white space in those files. Using the Github Desktop, I couldn't access the local copy of the unpacked zipfile but I cloned a new repository off it, which created the three git config files. It didn't copy anything else, so I file-copied all of the unpacked filesystem (except the git configuration files) into it. That sort of worked and it was able to link back to your github repository and log me in from the local config. I'm sure that's not how it's done but at least I am comfortable with the migrated file formats and filesystem structure, so far. It looks possible that I will be able to sync the working source files with the git ones, much as I was doing with CVS and SVN. Helen -- Kind regards, Helen Borrie |
|
From: Mark R. <ma...@la...> - 2017-10-17 08:59:10
|
On 16-10-2017 22:58, Helen Borrie wrote: > I guess I have to say (to quote my ex-Navy husband) "that's life in a > blue suit." My preference would have been to convert to SVN and leave > the repository on Sourceforge - don't fix what aint broke. But Github > seems to dominate our (project) lives these days. > > Currently, with the CVS and SVN clients I use - necessarily on > Windows, since our doc app is Windows-based - I can commit, check out, > etc. from a right click on the /manual/ subdir, or any subdir beneath > it. Given that I'm committing to multiple projects, this is a > blessing that I will miss badly. You can use a subversion client if you want: GitHub provides a compatibility layer that will make a git repository accessible as if it is a subversion repository. > After all these months with the core project on GitHub, I have yet to > succeed in downloading the repository AT ALL to access the readme > files in the core tree for use in the release notes. I have to rely > on Dmitry sending me a link, from which I can view a file and > copy/paste it into my local resource directory for that version. That sounds problematic. Could you send me a private email with the problems you run into? > As for code control, I currently keep two copies of the /manual/ > branch: one for working on and the other which I sync with the > working one before committing. I have no idea how I will manage with > the Github thing. Any docs I have read so far (and I have not tried > in recent months) assumes that one is working on the entire source > code tree. I do NOT want to keep a current copy of the entire tree. > To consult core source code, it is simple for me to find what I want > in the repository and copy/paste it, since I never commit changes to > that code. You will not need to checkout the Firebird sources to work with the documentation: they will be separate, individual, repositories, instead of one big repository with 'modules'. And as to working like you currently do: you could still do it that way, but using git to its fullest might make things easier after the initial learning curve. In git you can make local branches, commit changes to that local branch, and you can easily switch between the master branch and that local branch. Once you are happy with that, you can merge that local branch back to master with the commits you made on the local branch and 'push' that to the repository on GitHub. You could 'squash' the changes in the local branch to a single commit on master (but that is a bit more 'advanced' git). On the other hand, for Jaybird I use separate local copies for Jaybird 4 (master branch), Jaybird 3 (Branch_3_0) and Jaybird 2.2 (Branch_2_2), because that is simpler with uncommitted changes in progress. > I guess I just have to work something out. This is about the worst > week Mark could have picked, from my POV, as I'm already burning the > midnight oil on other project infrastructure problems and TRYING (in > conjunction with Denis Simonov) to sort out the Ringlish translation > of the FB Developer's Guide. The fact that I did the test conversion this weekend does not put a rush on you. We have until the 30th of November before we lose write access to the CVS repository, moving before that time would probably be better, but we can still move after that time if that is better for your schedule. However it would be great if there are more eyes on the conversion than just me. For example with the test conversion of OdbcJdbc, Alexander already found a conversion issue that I hadn't detected because he used the GitHub subversion support, and the git client automatically 'fixed' the issue. If necessary I can also grant write access to the test repository. > Note that Denis will have to be "in" on any changes as, this time > around, he is planning to convert the Word text to DocBook himself and > (presumably) commit the DocBook source once he has built it > successfully. Amongst other things, he has quite a number of > screenshots there which, of course, are binary files. I have no idea > how GH deals with image files but I guess we are going to find out > soon enough. I can't walk him through it myself, since I am clueless > about how it's going to work. Git by default uses a few heuristics to determine if a file is binary or not, and you can override that by explicitly setting the behavior for a file pattern in the .gitattributes file, like I did for the test conversion (see https://github.com/mrotteveel/test-firebird-documentation-3/blob/master/.gitattributes ). I already added the most likely image types to that file. Adding new types is just a matter of editing that file. Mark -- Mark Rotteveel |
|
From: Mark R. <ma...@la...> - 2017-10-17 09:15:59
|
On 17-10-2017 06:44, Helen Borrie wrote: > I downloaded the zip from your repository and looked at a few of the > .docbook files from the v.3.0.2 release notes with the editor I use > for creating and updating them. They look OK to me. > The ReadMe file in the base directory has messed-up line-endings, > though. I guess we'll need to test what happens when one of the > (currently good) source files gets updated. We definitely cannot do > with extraneous white space in those files. Git normalizes line-endings of text files in its internal storage to LF, when you checkout the file on a Windows git client (depending on configuration), it converts those line endings back to CRLF in the local working copy. This allows for ease of inter-operating between linux and friends (LF) and Windows (CRLF). The zip file generated by GitHub however uses the files as stored in the default format (or at least, it behaves as if the file is created on Linux). > Using the Github Desktop, I couldn't access the local copy of the > unpacked zipfile but I cloned a new repository off it, which created > the three git config files. It didn't copy anything else, so I > file-copied all of the unpacked filesystem (except the git > configuration files) into it. That sort of worked and it was able to > link back to your github repository and log me in from the local > config. The zipfile download from GitHub is a copy of the data in the repository, it is not a repository itself. That is probably why you can't just access it with GitHub Desktop, as that expects a 'real' git repository. > I'm sure that's not how it's done but at least I am comfortable with > the migrated file formats and filesystem structure, so far. It looks > possible that I will be able to sync the working source files with the > git ones, much as I was doing with CVS and SVN. You should be able to also use subversion by pointing it to https://github.com/mrotteveel/test-firebird-documentation-3 I haven't tested that yet, and I expect it may need some additional tweaking of the .gitattributes configuration. I have also 'invited' you as a collaborator to the test conversion if you want to test write access. Mark -- Mark Rotteveel |
|
From: Mark R. <ma...@la...> - 2017-10-17 10:00:24
|
On 17-10-2017 11:15, Mark Rotteveel wrote: >> I'm sure that's not how it's done but at least I am comfortable with >> the migrated file formats and filesystem structure, so far. It looks >> possible that I will be able to sync the working source files with the >> git ones, much as I was doing with CVS and SVN. > > You should be able to also use subversion by pointing it to > https://github.com/mrotteveel/test-firebird-documentation-3 > > I haven't tested that yet, and I expect it may need some additional > tweaking of the .gitattributes configuration. I just tested GitHub subversion support, but it doesn't apply the line-ending config from .gitattributes. I had hoped it would automatically apply 'svn:eol-style=native' properties to text files, but instead it will return the files bare as stored in the repository (which means LF line-endings for text files). This makes it next to useless on Windows unless you use tools that will apply LF line-endings consistently. That means it is probably better to ignore the presence of subversion support in GitHub. Mark -- Mark Rotteveel |
|
From: Norman D. <No...@du...> - 2017-10-17 13:13:05
|
If anyone is interested, Pro Git (Second Edition) by Scott Chacon and Ben Straub is officially available as PDF or EPUB from Springer's Web Site at https://www.springer.com/gb/book/9781484200773 - I believe that Springer are associated with Apress who publish the book. The book is also available to read online at https://git-scm.com/book/en/v2 - which is interesting as I'm sure I've downloaded the PDF from there in the past. (Must check!) You can also get the ASCIIDOC source code for the book from Github at https://github.com/progit/progit2 and build a copy for yourself. The book is Open Source, (CC Attribution Non-Commercial Share-alike 3.0 Unported Licence) and you are encouraged to fix errors and create pull requests to get the corrections (and your name!) in the next edition. ;-) HTH Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 |
|
From: Paul B. <pb...@ma...> - 2017-10-17 13:59:56
|
> I'm sure I've > downloaded the PDF from there in the past. (Must check!) https://link.springer.com/book/10.1007%2F978-1-4842-0076-6 Regards Paul |
|
From: Norman D. <No...@du...> - 2017-10-17 15:20:29
|
On 17/10/17 14:41, Paul Beach wrote: >> I'm sure I've >> downloaded the PDF from there in the past. (Must check!) > > https://link.springer.com/book/10.1007%2F978-1-4842-0076-6 > > Regards > Paul > Thanks Paul, but I was referring to the fact that I had, in the past, downloaded the book from the https://git-scm.com/book/en/v2 address. :-) I already have it from the Springer address too, so I have both versions. Thanks again. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 |
|
From: Paul B. <pb...@ma...> - 2017-10-17 15:30:50
|
> > https://link.springer.com/book/10.1007%2F978-1-4842-0076-6 > Thanks Paul, but I was referring to the fact that I had, in the past, > downloaded the book from the https://git-scm.com/book/en/v2 address. :-) > > I already have it from the Springer address too, so I have both versions. I just threw the link up, should anybody on Firebird docs want to download it. Personally I am still learning git too... Paul |
|
From: Helen B. <he...@ii...> - 2017-10-18 01:41:06
|
Hello Mark, Tuesday, October 17, 2017, 9:59:01 PM, Mark wrote: >> Currently, with the CVS and SVN clients I use - necessarily on >> Windows, since our doc app is Windows-based - I can commit, check out, >> etc. from a right click on the /manual/ subdir, or any subdir beneath >> it. Given that I'm committing to multiple projects, this is a >> blessing that I will miss badly. > You can use a subversion client if you want: GitHub provides a > compatibility layer that will make a git repository accessible as if it > is a subversion repository. The only reason to entertain the idea of using SVN would be if the CVS repository were converted to SVN and retained on SF. Since everything is moving towards a Git repository on GitHub, there's no reason to put SVN in the picture at all. >> After all these months with the core project on GitHub, I have yet to >> succeed in downloading the repository AT ALL to access the readme >> files in the core tree for use in the release notes. I have to rely >> on Dmitry sending me a link, from which I can view a file and >> copy/paste it into my local resource directory for that version. > That sounds problematic. Could you send me a private email with the > problems you run into? From my dabblings with your test project yesterday, I think my problems are with the Git desktop, mostly. I don't like the UI much at all, although being able to connect from it to the source project is a nice feature, but not a life saver. When I get clear of the current crop of alligators, I'll download the Tortoise client app as the TortoiseCVS and SVN packages always served me adequately. > You will not need to checkout the Firebird sources to work with the > documentation: they will be separate, individual, repositories, instead > of one big repository with 'modules'. OK, I'll take your word for it. ;-) Once I get an initial setup, I think I'll be good to go. But I strongly doubt I'll have the time for deep study this week or next. > And as to working like you currently do: you could still do it that way, > but using git to its fullest might make things easier after the initial > learning curve. I agree; thanks to your demo, I'm comfortable that I will be able to sync with the source repo without the whitespace and line-ending problem. I think getting the way updates and commits work will come when I'm not under as much stress as Firebird issues are giving me right now. As for the images for the Developer's Guide, the Ringlish text I'm editing is in Word and the screenshots are (probably) .wmf. But, as the screenshots are all in Russian/Cyrillic, someone with Visual Studio is going to have to re-shoot them from an English language environment, anyway. AFAIR, images we have used in the past have been .png, but Paul V. might have some preference, anyway. Helen |
Thanks for helping keep SourceForge clean.
X