Sysadmin Load Reduction: Subversion Infrastructure

[Ilya Bizyaev]

A task shows this attitude much better as it is something that will be completed eventually. "[WIP] Migrate translations from SVN to Git" to me sounds like a clear intention.



Docs, in contrast, are static and do not display any motivation for migration. "Top 10 Reasons Why We Can't Use Git".



Best regards,

Ilya.



---- Дата: Вт, 12 ноя 2019 14:12:28 +0300 Luigi Toscano <luigi.toscano at tiscali.it> написал(а) ----



Ben Cooksley ha scritto: 
> On Tue, Nov 12, 2019 at 10:00 AM Alexander Potashev 
> <mailto:aspotashev at gmail.com> wrote: 
>> 
>> пн, 11 нояб. 2019 г. в 17:02, Luigi Toscano <mailto:luigi.toscano at tiscali.it>: 
>>> 
>>> Alexander Potashev ha scritto: 
>>>> вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano <mailto:luigi.toscano at tiscali.it>: 
>>>>> 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. 
>>>> 
>>>> 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 
>>> 
>>> When I talk about local merges, I foresee a bit of mess when resolving a merge 
>>> locally, which may result in proper commits whose content has an invalid syntax. 
>> 
>> I don't get it. 
>> 
>> If you have conflicting changes, either with SVN or Git, you have to 
>> resolve the conflict manually. Of course it's easy to break the syntax 
>> while doing so, however SVN does not make it any easier than Git. 
>> 
>>>> 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 
>>> 
>>> Documentation does not seem to help (or at least I don't seem to find it in 
>>> the man pages for git 2.24). Do you know how it could filter just some 
>>> directories? It seems more focused on filtering by object type. 
>> 
>> OK, I now tried this approach with Git 2.23 (see attached log) and 
>> found horrible problems that make it basically unusable: 
>> 
>>  1. git-checkout downloads each file in a new SSH connection. It make 
>> the download really slow: less than 1 file per second in my setup. 
>> That means downloading of translations into one language would take 
>> more than an hour. 
>> 
>>  2. git-status silently tries to download to whole Git repository. 
>> 
>>  3. git-commit tries to download some files one by one again. 
>> 
>>>> Shall I create a new Phabricator task "[WIP] Migrate translations from 
>>>> SVN to Git" so we can put relevant ideas in one place? 
>>> 
>>> I don't know. For me having a board and tasks (it's not just a single task, 
>>> it's an entire project) sounds like there is something that can be 
>>> implemented, and I don't think it's the case. 
>> 
>> The tag [WIP] would hint that we are not sure if it can be 
>> implemented. We can even name it "Reasons why translations cannot 
>> migrate to Git", if necessary. 
> 
> Sorry, but if you proceed with using a title such as that one, then 
> you are not being constructive or helpful towards this conversation. 
> 
> That title would indicate to me that the translation community is 
> completely unwilling to consider change of any form. 
 
That's why it shouldn't be a task at this point, but a document showing why we 
can't migrate. 
It's not a matter that we are unwilling to consider. The problem is that the 
current state makes it almost impossible to migrate. The document would 
explain why. 
 
 
-- 
Luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20191112/8631aac2/attachment.htm>