Update on Status of Gitlab Migration
Johan Ouwerkerk
jm.ouwerkerk at gmail.com
Sat Apr 11 23:49:33 BST 2020
On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne <mpyne at kde.org> wrote:
>
> On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
>
> >
> > A cleanup script could be handy. I think kdesrc-build will
> > automatically pick up new repo paths from metadata and that should
> > work transparently, but the old clones may get left behind as well.
> > People who use the kdesrc-build option to ignore KDE repo structure
> > shouldn't be affected at all.
>
> (...)
>
> All of the kde: repositories use the kde:foo syntax, where the 'foo'
> comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML
> files.
>
Yes the only reason why a cleanup script might be needed is if the
logical path used to express the repo in dependency information
changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
remapped to `frameworks/kf5/foo` or something like that. In that case
unless you use the flat repository layout, kdesrc-build would try to
clone a new `frameworks/kf5/foo` repo, leaving your old
`frameworks/kf5foo` to consume some wasted disk space.
>
> We may need to do on-the-fly conversion of the kde: repo paths if they
> won't be expressible as 'kde:foo' in the future, but we should have the
> information needed to do this in kdesrc-build to make this happen
> on-the-fly.
>
Yes, this should be fairly straight forward: we could do a `git remote
set-url` based on what the repo metadata tells us before updating a
local clone. In fact: we could build this right now and sell it as
"automagically recover your upstream". :)
I might try to hack something up tomorrow or monday for that.
Regards,
- Johan
More information about the kde-core-devel
mailing list