| Hi Zoltan,
the composite repo is a fine idea. I tested it and it works pretty well. I am currently working on the migration and will notify here as soon as its completed.
Cheers, Alexander
Hi,On 06 Jun 2016, at 11:50, Alexander Nyßen <nyssen@xxxxxxxxx> wrote:
Hi,
Am 06.06.2016 um 11:21 schrieb Zoltán Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx>:
Hi,
2) I would be careful about renaming repositories; it could cause strange surprises, e.g. the GEF repository at github (https://github.com/eclipse/gef) was forked 34 times, and starred 13 times. Simply renaming is entirely ok, but then moving another repository to have the same name can be a source of confusion…
Up to now the repositories are only mirrored, so I suppose they will have to replaced anyway. I don’t know how that could be done in a way that forks can be preserved (or if its possible at all). I will try to find that out and add respective comments to https://bugs.eclipse.org/bugs/show_bug.cgi?id=495455.
If a repository is renamed on Github, some kind of internal redirects are added, so the references (e.g. mirrors remain). We have experienced this by moving repositories between organizations. However, I have no idea what happens if a new repository is created with the name of a renamed repository. I have absolutely no problem with renaming the repository to make it clear what is being developed, etc., but I don’t really like the idea of having a new repository with the old name that is totally independent (in a git sense) from the old one.
This could be problematic, as we want to replace the mirrored repositories with ‚native‘ ones.
I see. Maybe we won’t have a choice then, at least depending on how these mirror scripts are set up.
4) What is not clear to me in this proposal whether release update site urls would be changing. I have no problem with changing CI update site urls, but release urls should remain stable (or at least, redirect to the new ones, e.g. with a composite repository), as they can be referred to in existing installations as well.
Yes, I am thinking of actually changing the update sites for the GEF 3.x components as follows:
-Draw2d 3.x / GEF (MVC) 3.x, Zest 1.x Releases:
http://download.eclipse.org/tools/gef/updates/releases/ -> http://download.eclipse.org/tools/gef/updates/legacy/releases or http://download.eclipse.org/tools/gef/legacy/updates/releases
Draw2d 3.x / GEF (MVC) 3.x, Zest 1.x Milestones:
http://download.eclipse.org/tools/gef/updates/milestones/ -> http://download.eclipse.org/tools/gef/updates/legacy/milestones/ or http://download.eclipse.org/tools/gef/legacy/updates/milestones
-Draw2d 3.x / GEF (MVC) 3.x, Zest 1.x Integration:
http://download.eclipse.org/tools/gef/updates/interim/ -> http://download.eclipse.org/tools/gef/updates/legacy/integration/ or http://download.eclipse.org/tools/gef/legacy/updates/integration
If we could keep the old urls in place through symlinks for now (I have played a bit with using symbolic links yesterday and have contacted the webmaster for help), this is something I would like to adjust already today, so we would already have them in place for Neon (which would allow us to start using the original urls for the Oxygen train). It would also allow mirrors to properly sync during the quiet week. We could then think of further options (leave the symlinks, replace them with new content, aggregate them in a composite repo) after the Neon release.
We have seen some problems with symlinks, especially wrt mirrors not handling them correctly. However, using composite repositories instead of symlinks is almost as simple, and solves this in a transparent way. Otherwise, I am fine with the proposed structure.
The repos are already composite, but we have separate ones for GEF3 and GEF4, as both are populated from different builds. We could think of having a single update site for both streams, but then we would then probably also have to merge the code bases and releng infrastructure (and I am not sure if this is benefitial).
Sorry, it seems I was not clear enough, I did not propose to merge the two repositories/build scripts. If the urls are already composite, it is trivial to add the new urls there, so everything is backwards compatible, and maybe there is no need to rely on symlinks in the filesystem.Best regards,Zoltán-- Zoltán UjhelyiEclipse Technologies ExpertIncQueryLabs Ltd._______________________________________________gef-dev mailing listgef-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/gef-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nyssen@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
|
