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
------------------------------------------------------------------------------
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
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs
