On 18/12/16 02:24, Helen Borrie wrote: >> Mark Rotteveel wrote: >> >> > Isn't it time to consider migrating the documentation repository from >> > SourceForge CVS to GitHub? >> > >> > SourceForge itself considers CVS deprecated, and having the repository >> > on GitHub might increase visibility and will likely lower the barrier >> > for contribution. > *Helen Borrie:* I don't see how moving the source from one obscure > repository to a different obscure repository would heighten visibility > or lower any barrier. > > If there's a good reason to change, I'd go with it, albeit it currently > aint broke so there be nothing to fix. PaulV has it nicely set up for > use by the translators and it is all well documented, enough so that > those of us who actually DO stuff regularly, rather than just talk about > doing it, have our local setups that are more or less automated. One of > us can always step in to assist people who don't want to work with a > repository for whatever reason. I don't see how changing the repository > would (or should) alter that. > My personal experience so far with GitHub is that it is a dog to work > with, actually, given that I don't upload or download any programming > code, only documentation. I guess if I had to, I'd find a way to make > it useful for me to use. I just can't think of a good reason right now > to spend time and energy on creating a solution to a non-existent problem.
CVS still has a number of plus features that github deliberately destroyed in order to make supporting CODE a priority. When PHP project was looking to move - yet again - Hg get the vote for a system that worked better, but the 'github' marketing angle won the day - even given it's know faults! So now I have an Hg/Mercurial setup locally, which handles CVS, SVN and GIT transparently and allows working easily between all four. BUT I would still prefer the clean way that CVS handled modular project. GIT ( and actually Hg) still does not accept that scripted languages and documentation is much better handled as a series of inter-related projects rather than one all encompassing code base. sub-repo's are frond on in both while CVS modules are still a perfect solution, and projects that broke perfectly good CVS repositories into a series of GIT repo's still have no tools to put the hwole back together again. PHP still has not plugged all the holes in it's GIT process and often gets cross contamination, so until there IS a reason to change ... why create all that extra work? And certainly don't put anything on github ... use a private git repository which is the one thing PHP has right. -- 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 ------------------------------------------------------------------------------ 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
