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

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

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