[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Sysadmin Load Reduction: Subversion Infrastructure
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-11-12 17:26:34
Message-ID: CA+XidOEQKkXXp=SdWLQ=szYp5XQ79zucVhbYZuDao=O7bi-t_Q () mail ! gmail ! com
[Download RAW message or body]

On Wed, Nov 13, 2019 at 12:12 AM Luigi Toscano <luigi.toscano@tiscali.it> w=
rote:
>
> Ben Cooksley ha scritto:
> > On Tue, Nov 12, 2019 at 10:00 AM Alexander Potashev
> > <aspotashev@gmail.com> wrote:
> >>
> >> =D0=BF=D0=BD, 11 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0=B3. =D0=B2 17:02, =
Luigi Toscano <luigi.toscano@tiscali.it>:
> >>>
> >>> Alexander Potashev ha scritto:
> >>>> =D0=B2=D1=81, 10 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0=B3. =D0=B2 18:09=
, Luigi Toscano <luigi.toscano@tiscali.it>:
> >>>>> Most of translators are not so technical as the developers. And eve=
n
> >>>>> developers can shoot them in the foot with git, I see many issues c=
oming 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-c=
ommit
> >>>
> >>> When I talk about local merges, I foresee a bit of mess when resolvin=
g a merge
> >>> locally, which may result in proper commits whose content has an inva=
lid 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, howev=
er
> >>>> 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 som=
e
> >>> 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 fr=
om
> >>>> 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 w=
hy 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.

Spin that around please. It should instead be 'Challenges to migrate to Git=
'.

This is an exercise Sysadmin is reasonably familiar with when it comes
to any system transition - there are always workflows and processes
that need to be adjusted, tooling that needs to be tweaked or
rewritten, data that needs to be migrated, etc.

>
>
> --
> Luigi

Cheers,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]