Sysadmin Load Reduction: Subversion Infrastructure

Ben Cooksley bcooksley at kde.org
Tue Nov 12 17:26:34 GMT 2019


On Wed, Nov 13, 2019 at 12:12 AM Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>
> Ben Cooksley ha scritto:
> > On Tue, Nov 12, 2019 at 10:00 AM Alexander Potashev
> > <aspotashev at gmail.com> wrote:
> >>
> >> пн, 11 нояб. 2019 г. в 17:02, Luigi Toscano <luigi.toscano at tiscali.it>:
> >>>
> >>> Alexander Potashev ha scritto:
> >>>> вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano <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.

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



More information about the kde-community mailing list