Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley <bcooksley-RoXCvvDuEio at public.gmane.org> wrote:
>
> On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk <jm.ouwerkerk-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> >
> > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk <jm.ouwerkerk-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> > >
> > > 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.
> > >
> >
> > This is obviously a poor example, but the same problem occurs if
> > something moves from playground to extragear. Basically if the
> > `projectpath` YAML key changes.
>
> I had been considering adding the Gitlab Project ID number to the YAML
> metadata files as a way of allowing us to track projects through their
> whole lifetime.
>

That would be very nice, because then `kdesrc-build` could implement
an `arc patch` type feature in a more straightforward fashion. So
people could type things like `kdesrc-build juk!55` as a shorthand for
checkout remote HEAD of whatever branch MR 55 is for `juk`.

Regards,

- Johan