вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano <luigi.tosc...@tiscali.it>: > > Nate Graham ha scritto: > > On 11/9/19 4:50 PM, Nicolás Alvarez wrote: > >> El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) > >> escribió: > >>> > >>> Not knowing anything about the translation system we use... what are the > >>> blockers to moving it over to git? > >>> > >> Not necessarily in order: > >> - Experiment conversion to git and see if the resulting repo(s) are of > >> a reasonable size (I vaguely recall seeing bad results with this) > >> - Convince and teach every translator to use git (expect lots of friction > >> here) > >> - Make scripty use git instead of svn (likely lots of work) > >> - Some language teams have their own tooling (local for translation, > >> or web for statistics) that would need to be gitified too. For > >> example, the Spanish team developed KSvnUpdater. > >> - Update lots of documentation in different languages (eg. > >> https://es.l10n.kde.org/repositorio.php) > >> > >> You may even need to migrate languages one by one (as you convince > >> each language team?), so in the meantime all tooling would need to > >> support both repos at the same time. > >> > >> It doesn't sound like fun... > > > > Thanks for the background. > > > > If we're going to keep SVN, I think we need to fully support it. If we don't > > have the resources to do this on an ongoing basis, then we need to invest > > the > > resources now/soon to move away from it. I don't see any other realistic > > options. > > New resources is the solution. Please see the other emails: the problem > discussed is not subversion itself, but the web interface. > > > > > Again, from a totally non-translation perspective, I am somewhat surprised > > to > > hear that individual translators are required to be proficient in a source > > control system. Perhaps de-coupling the workflow from direct interaction > > with > > the SCM would be beneficial? Isn't this what GUI apps like KLocalize do? If > > not, can it be modified to do the SCM interaction? This seems like a > > solvable > > problem. > > Most of translators are not so technical as the developers. And even > developers can shoot them in the foot with git, I see many issues coming from > unwanted merges. > Also, in addition to some of the problem described above (not all of them are > blocker IMHO), more relevant: how would you convert the SVN repositories into > git? > - a unique repository would be the easier way, and required by people who do > changes to all the languages (renamed and moves) but I can only foresee tons > of merging issues when committing (see above). > - a repository per language would mean a tons of work whenever you need to do > a global operation, and right now it's a no go.
Hi Luigi, We can block unwanted merged on the server with a Git hook like this: https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-commit > >> - Experiment conversion to git and see if the resulting repo(s) are of > >> a reasonable size (I vaguely recall seeing bad results with this) I expect that a single Git repository would be several GBs in size. Cloning the whole repo would be too much for some translators, however the new Git feature "git clone --filter" might be a solution: https://unix.stackexchange.com/a/468182 Shall I create a new Phabricator task "[WIP] Migrate translations from SVN to Git" so we can put relevant ideas in one place? -- Alexander Potashev