firebird-docs — chat stuff about documentation

Re: [Firebird-docs] Test repository CVS to git migration

[Helen B. <he...@ii...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

[Helen B. <he...@ii...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] Test repository CVS to git migration

[Helen B. <he...@ii...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] Test repository CVS to git migration

[Norman D. <No...@du...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] Test repository CVS to git migration

[Paul V. <pa...@vi...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

[Norman D. <No...@du...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

[Paul V. <pa...@vi...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

[Köditz, M. <Mar...@it...>]

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

Re: [Firebird-docs] ATTN committers: SourceForge to terminate CVS support on November 30th

[Lester C. <le...@ls...>]

On 18/10/17 02:40, Helen Borrie wrote:
>>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.

Where I'm having to work with projects that perhaps jumped to git too
soon, I'm using TortoiseHg with git-hg. It provides views and navigation
tools that I've been used to and gives a common base for CVS and SVN as
well as GIT and the native HG which I've been using locally as an
alternative to GIT. I don't know about the current GIT UI tools but it
was simply not cross platform and complete at the time I was having to
live with the change ... In my book GIT may have filled holes in CVS
operations, but it also lost key facilities CVS was good at. The
resulting project ports are now difficult to work with as a whole where
one has dozens of isolated module which on CVS one could create a single
view of selected 'sub-repos' :(

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Re: [Firebird-docs] ATTN committers: SourceForge to terminate CVS support on November 30th

[Helen B. <he...@ii...>]

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

Re: [Firebird-docs] Error while building PDF

[Norman D. <No...@du...>]

No worries, glad to hear it worked.

Cheers,
Norm.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Firebird-docs] Error while building PDF

[Köditz, M. <Mar...@it...>]

Hi Norman,

for the sake of completeness, I have now used Oracle's JRE. As you expected, there were no more problems.

Regards,
Martin

Re: [Firebird-docs] Test repository CVS to git migration

[Paul B. <pb...@ma...>]

> > 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

Re: [Firebird-docs] Test repository CVS to git migration

[Norman D. <No...@du...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] Test repository CVS to git migration

[Paul B. <pb...@ma...>]

> 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

Re: [Firebird-docs] Test repository CVS to git migration

[Norman D. <No...@du...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] ATTN committers: SourceForge to terminate CVS support on November 30th

[Kjell R. <kje...@ma...>]

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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

Re: [Firebird-docs] Test repository CVS to git migration

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

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