Menu
▾
▴
firebird-docs
|
From: Köditz, M. <Mar...@it...> - 2017-10-17 06:12:14
|
Hi, seems I got unsubscribed from the list. So I had some trouble to be part of the discussion. I will try it again. Do we have any problems with special characters? Please have a look at https://github.com/mrotteveel/test-firebird-documentation-3/tree/master/src/docs/refdocs-de/langref/fblangref25. Here you can see some hieroglyphs in the commit messages. Regards, Martin |
|
From: Köditz, M. <Mar...@it...> - 2017-10-18 08:34:33
|
Hi Mark, I used your repository for few Tests and further translation. I couldn't find any problems. The Linux scripts are working and no strange behavior when I create the html or pdf outputs. >From my point of view everything is fine and it is much easier to add new contents (for me). Regards, Martin |
|
From: Köditz, M. <Mar...@it...> - 2017-11-02 09:27:22
|
Hello everybody, I've worked with Mark's Git repo for a while. I haven't found any problems yet. So I think we should really migrate. I had a few requests regarding the move. More translators want to collaborate based on the Git environment. So far, I had to put these off. It would be nice to get these people on board. So what are the next steps? Regards, Martin |
|
From: Mark R. <ma...@la...> - 2017-11-04 12:42:34
|
On 2-11-2017 10:27, Köditz, Martin wrote: > Hello everybody, > > I’ve worked with Mark’s Git repo for a while. I haven’t found any > problems yet. So I think we should really migrate. > > I had a few requests regarding the move. More translators want to > collaborate based on the Git environment. So far, I had to put these > off. It would be nice to get these people on board. > > So what are the next steps? I'm waiting on Helen to give the final go. I have found one minor issue with .sh files not being marked executable (relevant on Linux), but I have a fix for that. And although it is not an impediment for the migration itself, it would be handy to have a list of the GitHub usernames of contributors that need commit access to the repository. Alternatively, contributors could use forks and use pull requests for their contributions. Mark -- Mark Rotteveel |
|
From: Norman D. <No...@du...> - 2017-11-04 15:01:04
|
Hi Mark, On 04/11/17 12:42, Mark Rotteveel wrote: > And although it is not an impediment for the migration itself, it would > be handy to have a list of the GitHub usernames of contributors that > need commit access to the repository. Mine is "NormanDunbar" - if you want it now that is! > Alternatively, contributors could use forks and use pull requests for > their contributions. I think that this might be the better idea, but it will mean that a "benevolent dictator" (or similar) would be required to actually check and merge the pull requests. It's reasonably simple to have a fork and keep it up to date with a remote pointing at the original repository, and a "git pull" from that remote. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 |
|
From: Helen B. <he...@ii...> - 2017-11-05 18:28:14
|
Sunday, November 5, 2017, 1:42:35 AM, Mark wrote: >>> So what are the next steps? > I'm waiting on Helen to give the final go. Actually, I was waiting to see some comment from Paul V. I still seem to have one or two novice issues on this side but they are not showstoppers. Over the weekend I cloned the #4 test and used it to create a private local/remote repository for the Developer's Guide stuff, as I am using a couple of experimental changes to the build ingredients. All is well, so far, I think. It will be a while before I need to push anything to the main repo. I don't think it will be too much of a problem to do that "with rule-book in hand" and Google alongside. Hats off to you for your efforts with this and the other CVS repo's, Mark! Cheers, Helen |
|
From: Mark R. <ma...@la...> - 2017-11-06 09:03:05
|
On 5-11-2017 19:27, Helen Borrie wrote: > Sunday, November 5, 2017, 1:42:35 AM, Mark wrote: > >>>> So what are the next steps? > >> I'm waiting on Helen to give the final go. > > Actually, I was waiting to see some comment from Paul V. As Paul has given his OK too, I will perform the migration next weekend (probably Saturday, maybe Sunday) > I still seem to have one or two novice issues on this side but they > are not showstoppers. Over the weekend I cloned the #4 test and used > it to create a private local/remote repository for the Developer's > Guide stuff, as I am using a couple of experimental changes to the build > ingredients. Be aware that you will need to make a fresh clone of the final repository once I've done the 'real' migration. Or at least, otherwise you'll need to do some complex steps to reconcile / merge them. Mark -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2017-11-06 02:28:04
|
Helen wrote: >> I'm waiting on Helen to give the final go. > > Actually, I was waiting to see some comment from Paul V. And I was waiting for yours, since you were the only one with potential issues regarding Git :-) Anyway, since you seem to be confident it will work for you now, I'm neutral and all others are in favour, let's do it! > Hats off to you for your efforts with this and the other CVS repo's, > Mark! Hear, hear! Mark, my Github username is paulvink. Cheers, Paul |
|
From: Köditz, M. <Mar...@it...> - 2017-11-06 14:10:45
|
Hi Mark, my Github username is MartinKoeditz. Regards, Martin -----Ursprüngliche Nachricht----- Von: Paul Vinkenoog [mailto:pa...@vi...] Gesendet: Montag, 6. November 2017 03:28 An: Chatter regarding Firebird documentation <fir...@li...> Betreff: Re: [Firebird-docs] Test repository CVS to git migration Helen wrote: >> I'm waiting on Helen to give the final go. > > Actually, I was waiting to see some comment from Paul V. And I was waiting for yours, since you were the only one with potential issues regarding Git :-) Anyway, since you seem to be confident it will work for you now, I'm neutral and all others are in favour, let's do it! > Hats off to you for your efforts with this and the other CVS repo's, > Mark! Hear, hear! Mark, my Github username is paulvink. Cheers, Paul ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Firebird-docs mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-docs |
|
From: Mark R. <ma...@la...> - 2017-10-17 09:02:01
|
On 17-10-2017 08:12, Köditz, Martin wrote: > Hi, > > seems I got unsubscribed from the list. So I had some trouble to be part > of the discussion. I will try it again. > > Do we have any problems with special characters? Please have a look at > https://github.com/mrotteveel/test-firebird-documentation-3/tree/master/src/docs/refdocs-de/langref/fblangref25. > Here you can see some hieroglyphs in the commit messages. Thanks, I hadn't noticed those. I will add the `utf-8` filter for log messages for the next conversion attempt. Mark -- Mark Rotteveel |
|
From: Mark R. <ma...@la...> - 2017-10-17 14:32:11
|
On 17-10-2017 08:12, Köditz, Martin wrote: > Hi, > > seems I got unsubscribed from the list. So I had some trouble to be part > of the discussion. I will try it again. > > Do we have any problems with special characters? Please have a look at > https://github.com/mrotteveel/test-firebird-documentation-3/tree/master/src/docs/refdocs-de/langref/fblangref25. > Here you can see some hieroglyphs in the commit messages. Fixed in https://github.com/mrotteveel/test-firebird-documentation-4 Mark -- Mark Rotteveel |
|
From: Paul V. <pa...@vi...> - 2017-10-18 13:08:40
|
Mark Rotteveel wrote: > Fixed in https://github.com/mrotteveel/test-firebird-documentation-4 I cloned this repository and built a number of targets, both in master and in the B_Release branch. Everything worked exactly as in my CVS checkout. A number of source files in my (Windows) CVS working dir have Unix line endings though, whereas their Git counterparts have DOS endings. That's no problem, as long as it doesn't lead to a huge number of 'changes' and log messages when such a file is committed, cluttering the history and drowning the real changes. Anyway, I guess that won't occur if we commit all our work to CVS before the conversion/transition, get a fresh git clone afterwards and work only from that. Am I right? Cheers, Paul Vinkenoog |
|
From: Norman D. <No...@du...> - 2017-10-18 13:36:00
|
Afternoon Paul, On 18/10/17 14:08, Paul Vinkenoog wrote: > A number of source files in my (Windows) CVS working dir have Unix line endings though, whereas their Git counterparts have DOS endings. > > That's no problem, as long as it doesn't lead to a huge number of 'changes' and log messages when such a file is committed, cluttering the history and drowning the real changes. This is a documented feature of Git. Github has a document about how you can set up your git client to cope with this. The URL is https://help.github.com/articles/dealing-with-line-endings/. From the online "Pro Git" book, we have this from https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration (scroll down!): core.autocrlf If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key. Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code: $ git config --global core.autocrlf true If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input: $ git config --global core.autocrlf input This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository. If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false: $ git config --global core.autocrlf false So, windows users need: $ git config --global core.autocrlf true and Linux and Mac users need: $ git config --global core.autocrlf input > Anyway, I guess that won't occur if we commit all our work to CVS before the conversion/transition, get a fresh git clone afterwards and work only from that. Am I right? In a word, yes. Provided that you configure the Git client before checking out and definitely before checking in. 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 V. <pa...@vi...> - 2017-10-18 14:12:55
|
Hi Norman, >> A number of source files in my (Windows) CVS working dir have Unix line endings though, whereas their Git counterparts have DOS endings. >> >> That's no problem, as long as it doesn't lead to a huge number of 'changes' and log messages when such a file is committed, cluttering the history and drowning the real changes. > > This is a documented feature of Git. > > Github has a document about how you can set up your git client to cope > with this. The URL is > https://help.github.com/articles/dealing-with-line-endings/. (...) > So, windows users need: > > $ git config --global core.autocrlf true > > and Linux and Mac users need: > > $ git config --global core.autocrlf input > >> Anyway, I guess that won't occur if we commit all our work to CVS before the conversion/transition, get a fresh git clone afterwards and work only from that. Am I right? > > In a word, yes. Provided that you configure the Git client before > checking out and definitely before checking in. It's a bit risky to have it depend on the client, i.e. the individual user. But I see now that you can also take care of it in the .gitattributes file, and Mark has alreay done that. Cheers, Paul |
|
From: Mark R. <ma...@la...> - 2017-10-18 14:21:02
|
On 2017-10-18 15:35, Norman Dunbar wrote: > Afternoon Paul, > > On 18/10/17 14:08, Paul Vinkenoog wrote: > >> A number of source files in my (Windows) CVS working dir have Unix >> line endings though, whereas their Git counterparts have DOS endings. >> >> That's no problem, as long as it doesn't lead to a huge number of >> 'changes' and log messages when such a file is committed, cluttering >> the history and drowning the real changes. > > This is a documented feature of Git. > > Github has a document about how you can set up your git client to cope > with this. The URL is > https://help.github.com/articles/dealing-with-line-endings/. > > From the online "Pro Git" book, we have this from > https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration > (scroll down!): > > > core.autocrlf Although the information about core.autocrlf is correct, the presence of the .gitattributes with "* text=auto" will enable this with the platform specific line-endings even if you don't have core.autocrlf enabled or configured. Mark |
|
From: Mark R. <ma...@la...> - 2017-10-18 14:15:37
|
On 2017-10-18 15:08, Paul Vinkenoog wrote: > Mark Rotteveel wrote: > >> Fixed in https://github.com/mrotteveel/test-firebird-documentation-4 > > I cloned this repository and built a number of targets, both in master > and in the B_Release branch. > Everything worked exactly as in my CVS checkout. > > A number of source files in my (Windows) CVS working dir have Unix > line endings though, whereas their Git counterparts have DOS endings. Yes, those are the four files I mentioned earlier. I have normalized those files, so they will not get line-ending conversion issues in future updates. Git always uses LF for internal storage of text files, only on checkout / commit will it apply line-ending conversion to what is either configured in the client, or - in this case - by the .gitattributes file. > That's no problem, as long as it doesn't lead to a huge number of > 'changes' and log messages when such a file is committed, cluttering > the history and drowning the real changes. That shouldn't happen. I have double checked this by using `git read-tree --empty` after adding the .gitattributes, any issues with white space normalization between what is currently stored and what git would do when updating a file and applying the correct line-ending normalization should show up that way. > Anyway, I guess that won't occur if we commit all our work to CVS > before the conversion/transition, get a fresh git clone afterwards and > work only from that. Am I right? Given the normalization done during conversion, that should not be a problem (unless a new file extension is introduced that isn't considered a text file by the configuration of the conversion). And yes, it would be best to get a fresh clone after migration. Although performing a git clone and moving any files that were still under modification should not be a problem. Mark |
|
From: Norman D. <No...@du...> - 2017-10-18 14:45:23
|
On 18/10/17 15:15, Mark Rotteveel wrote: > Given the normalization done during conversion, that should not be a > problem (unless a new file extension is introduced that isn't considered > a text file by the configuration of the conversion). The thing I mentioned with autocrlf is the old way of doing things, up to Git 1.6 I think. From then on, .gitattributes is the way to go. However, if a new file type appears, Git will determine whether it is a text file by checking to see if it fails the tests for binary files. There's a good explanation of why it might be best to have both settings at http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/. 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...> - 2017-10-18 15:12:07
|
On 2017-10-18 16:45, Norman Dunbar wrote: > On 18/10/17 15:15, Mark Rotteveel wrote: > >> Given the normalization done during conversion, that should not be a >> problem (unless a new file extension is introduced that isn't >> considered a text file by the configuration of the conversion). > > The thing I mentioned with autocrlf is the old way of doing things, up > to Git 1.6 I think. From then on, .gitattributes is the way to go. Old way, but still the way if a repository has no .gitattributes (like for example the Firebird core repository). > However, if a new file type appears, Git will determine whether it is > a text file by checking to see if it fails the tests for binary files. Git's text file detection is pretty good, but I'm specifically talking about the line-ending normalization that I'm doing during the repository conversion process. I have decided to use a cautious approach, which means I'll only do line-ending normalization on files that are positively text files (based on a large list 'borrowed' from Subversion, with some project specific alterations, see https://www.lawinegevaar.nl/firebird/cvs_migration.html for details). All other files will be left untouched on the off chance they are binary, as the conversion process uses git fast-import to load the data, git will not apply its own line-ending normalization at that time (in essence, git fast-import handles everything as if it is binary). So if a new file extension for a text file would be introduced between now and the final conversion, then I would specifically need to take that into account, or we'll get a white space correction on the first commit that touches that file after migration. But odds are probably negligible that a new (and unknown) file extension will be introduced to the project before migration. Mark |
|
From: Helen B. <he...@ii...> - 2017-10-18 17:52:21
|
Thursday, October 19, 2017, 4:11:59 AM, Mark wrote: > So if a new file extension for a text file would be introduced between > now and the final conversion, then I would specifically need to take > that into account, or we'll get a white space correction on the first > commit that touches that file after migration. > But odds are probably negligible that a new (and unknown) file extension > will be introduced to the project before migration. You have .docbook in your set, right? I haven't had a chance to search for where you stored these suffixes but I assumed that .docbook must have been included, since the converted files I looked at seemed normal. I'm wondering whether the l/e problem with the file named ReadMe might be due to the lack of suffix. I have noticed that, since the core project was moved to GH, the guys have been giving suffixes to their readme files in .../doc/. The reason might be that this is a recognised quirk of Git..? Helen |
|
From: Mark R. <ma...@la...> - 2017-10-19 08:07:47
|
On 2017-10-18 19:52, Helen Borrie wrote: > Thursday, October 19, 2017, 4:11:59 AM, Mark wrote: > >> So if a new file extension for a text file would be introduced between >> now and the final conversion, then I would specifically need to take >> that into account, or we'll get a white space correction on the first >> commit that touches that file after migration. > >> But odds are probably negligible that a new (and unknown) file >> extension >> will be introduced to the project before migration. > > You have .docbook in your set, right? I haven't had a chance to > search for where you stored these suffixes but I assumed that .docbook > must have been included, since the converted files I looked at seemed > normal. Yes, I have it set in my conversion config, although I notice I didn't document that on https://www.lawinegevaar.nl/firebird/cvs_migration.html I also added it in the .gitattributes file, see https://github.com/mrotteveel/test-firebird-documentation-4/blob/master/.gitattributes > I'm wondering whether the l/e problem with the file named ReadMe might > be due to the lack of suffix. I have noticed that, since the core > project was moved to GH, the guys have been giving suffixes to their > readme files in .../doc/. The reason might be that this is a > recognised quirk of Git..? The line-endings of ReadMe are correct in my checkout, which means the git autodetection is working for me. I could add ReadMe explicitly in .gitattributes, but that shouldn't make a difference (it should already be caught by "* text=auto" in the .gitattributes). Are you saying ReadMe still has LF instead of CRLF in your checkout? As to the firebird repository, it doesn't use a .gitattributes, which imho is an oversight, I will bring it up in firebird-devel later. The switch to files with extensions pre-dates the switch to git (eg doc/README.connection_string_charset.txt is 8 years old, which puts it in the 'CVS'-era). It just isn't done consistently. Using file extensions does make it easier - at least on Windows - for end-users to open them in a text editor without having to use 'Open with' or similar extra steps. Since the switch to git, some of the readme files have been created as .md (markdown), but probably that is because GitHub will render that with nice formatting, eg compare https://github.com/FirebirdSQL/firebird/blob/master/README.md with the source https://raw.githubusercontent.com/FirebirdSQL/firebird/master/README.md Mark |
|
From: Helen B. <he...@ii...> - 2017-10-19 18:22:37
|
Thursday, October 19, 2017, 9:07:39 PM, Mark wrote: > The line-endings of ReadMe are correct in my checkout, which means the > git autodetection is working for me. I could add ReadMe explicitly in > .gitattributes, but that shouldn't make a difference (it should already > be caught by "* text=auto" in the .gitattributes). Are you saying ReadMe > still has LF instead of CRLF in your checkout? Don't worry about it for now. That observation was made on the files from the zip that I downloaded at the beginning of the week (#3 conversion). I should be able to get up to date with your test conversions at the weekend. > As to the firebird repository, it doesn't use a .gitattributes, which > imho is an oversight, I will bring it up in firebird-devel later. The > switch to files with extensions pre-dates the switch to git (eg > doc/README.connection_string_charset.txt is 8 years old, which puts it > in the 'CVS'-era). It just isn't done consistently. Using file > extensions does make it easier - at least on Windows - for end-users to > open them in a text editor without having to use 'Open with' or similar > extra steps. IMHO, it's a small "ask", considering that a number of those Readme files go out in the release distributions, in /doc/, for all platforms. A Tracker request might be the way to go. That's what got us version numbers in firebird.conf, eventually. Don't make the ticket a DOC one, though, as those who need to see it are unlikely to notice a DOC ticket. > Since the switch to git, some of the readme files have been created as > .md (markdown), but probably that is because GitHub will render that > with nice formatting, eg compare > https://github.com/FirebirdSQL/firebird/blob/master/README.md with the > source > https://raw.githubusercontent.com/FirebirdSQL/firebird/master/README.md That's interesting - and probably, in some abstruse way, accounts for my erstwhile belief that I couldn't get that content except by copy/pasting the text. Helen |
|
From: Helen B. <he...@ii...> - 2017-10-20 08:33:18
|
Friday, October 20, 2017, 7:22:25 AM, you wrote: > Thursday, October 19, 2017, 9:07:39 PM, Mark wrote: >> The line-endings of ReadMe are correct in my checkout, which means the >> git autodetection is working for me. I could add ReadMe explicitly in >> .gitattributes, but that shouldn't make a difference (it should already >> be caught by "* text=auto" in the .gitattributes). Are you saying ReadMe >> still has LF instead of CRLF in your checkout? I wrote: > Don't worry about it for now. That observation was made on the files > from the zip that I downloaded at the beginning of the week (#3 > conversion). I should be able to get up to date with your test > conversions at the weekend. I just did an actual clone of the test#4 repository and the Readme looks just as it ought to. I'm also abandoning the GitHub Desktop in favour of TortoiseGit. It feels familiar, even if I don't understand most of the lingo. I'll try to grokk that over the weekend, at least the bits I need to grokk. If I survive that, I might even have a go at cloning the doc branch of the main repository. Helen |
|
From: Kjell R. <kje...@ma...> - 2017-10-20 08:47:51
|
Helen Borrie wrote: > I just did an actual clone of the test#4 repository and the Readme > looks just as it ought to. I'm also abandoning the GitHub Desktop in > favour of TortoiseGit. It feels familiar, even if I don't understand > most of the lingo. I'll try to grokk that over the weekend, at least > the bits I need to grokk. > > If I survive that, I might even have a go at cloning the doc branch of > the main repository. As a person who also switched from SVN (not CVS) to Git, I'd recommend the official tutorial: https://git-scm.com/docs/gittutorial I think that was the one I found most instructive. Also, maybe, this one: https://www.tutorialspoint.com/git/index.htm It's funny that when Linus Torvalds started out with Git, his explicit goal was to avoid doing ANYTHING the way SVN does. :-) I don't know how you will handle tags in the docs project, but one thing I find is easy to miss in TortoiseGit is that when you push your local repo to origin, you always need to check the checkbox to include tags. That is, if your local tags are really supposed to be migrated to origin. The checkbox can't be defaulted to checked state. Regards, Kjell |
Thanks for helping keep SourceForge clean.
X