Re: [JPP-Devel] OpenJUMP migration documentation
uple of global ones -- core, plus, experimental, etc. --? a global one?). Their SVN structures differ, so it isn't going to be necessarily easy to deal with that, - would it be easier to create the plug-in manager before the migration? Could it help answering the last questions?, - there are all the questions about the different builds, especially for those which are related to the plug-ins, - is there a better way to link SVN authors with Git authors, rather than using the SourceForge user addresses? (historical commits would thus refer to current Git accounts) - etc. After migration, the current size of the OpenJUMP core as a Git repository is around 540MB. The 'docs' folder size alone is 70MB without the revision history, and 108MB if considered. By externalising it into another Git repository (the revision history would be kept as well), this would reduce the global size of the main core repository by already 20%. Some other folders could be considered. In the long term, this would probably make the global project easier to manage. I just did a quick test to create a private repository for the 'docs' folder. See (you need to be logged in to access it): https://github.com/openjump-gis/doc-test I used a tool directly provided by GitHub to automate the migration (https://github.com/new/import). It is quite handy but it is relatively difficult to create a proper mapping between the SVN and the Git users/authors. So what I would suggest is to create some wiki pages in the newly created openjump-migration-doc repository (https://github.com/openjump-gis/openjump-migration-doc) to write and discuss about the different options. A wiki is an easy way of communication, or issues could be created as well. Once discussed/closed, I could add some proper documentation to crystallise what has been decided. This suggestion, even if first perceived as time consuming, could allow us to migrate most the OJ repositories/components, if not all, in an easier way, and to save some a lot of time in the future. This would also allow, if needed, to restructure some parts of the project now (probably not the code itself, such as the tests, etc., but such as previously described based on the 'docs' folder) rather than later, especially if one goal is to reduce the global size of the repository. Once again, these are just suggestions, open to discussion. Eric >> What about listing the tickets or tasks we want to fix before migration (if >> possible something we can achieve within a few weeks). Then we could make a new >> release and concentrate on the migration. > agreed. we should at least prioritize. let me try to set up a milestone in the bug tracker. > > sorry for spamming the list, but setting up the searchable milestone on sf.net <http://sf.net> was a bit bothersome. > > we have 36 open bugs, which can now be assigned to a OJ_1.16 milestone now. when that's done we can search them on the left side via 'Open Tickets for OJ 1.16' and fix em one by one. > > hands up. who want's to tag'em? > >> Any other proposal somebody ? > not me :).. ede > >> Michaël >> >>> envoyé : 20 août 2020 à 17:58 >>> de : Eric mailto:eric.openj...@thefactory.io>> >>> à : jump-pilot-devel@lists.sourceforge.net <mailto:jump-pilot-devel@lists.sourceforge.net> >>> objet : Re: [JPP-Devel] OpenJUMP migration documentation >>> >>> >>> Just added the documentation to update JTS from 1.14 to 1.17. >>> >>> Eric >>> >>> On 20/08/2020 13:42, Eric wrote: >>> >>>> Hi, >>>> >>>> The first part of this documentation is now online: >>>> https://github.com/openjump-gis/openjump-migration-doc >>>> >>>> It focuses only on the migration from SVN to Git. >>>> >>>> Before migrating, the reading of this article could be useful as it >>>> contains some good practice tips: >>>> https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git >>>> >>>> >>>> Eric >>>> >>> >>> ___ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >> >
Re: [JPP-Devel] OpenJUMP migration documentation
t; > Eric > > >> What about listing the tickets or tasks we want to fix before migration > (if > >> possible something we can achieve within a few weeks). Then we could > make a new > >> release and concentrate on the migration. > > agreed. we should at least prioritize. let me try to set up a milestone > in the bug tracker. > > > > sorry for spamming the list, but setting up the searchable milestone on > sf.net was a bit bothersome. > > > > we have 36 open bugs, which can now be assigned to a OJ_1.16 milestone > now. when that's done we can search them on the left side via 'Open Tickets > for OJ 1.16' and fix em one by one. > > > > hands up. who want's to tag'em? > > > >> Any other proposal somebody ? > > not me :).. ede > > > >> Michaël > >> > >>> envoyé : 20 août 2020 à 17:58 > >>> de : Eric > >>> à : jump-pilot-devel@lists.sourceforge.net > >>> objet : Re: [JPP-Devel] OpenJUMP migration documentation > >>> > >>> > >>> Just added the documentation to update JTS from 1.14 to 1.17. > >>> > >>> Eric > >>> > >>> On 20/08/2020 13:42, Eric wrote: > >>> > >>>> Hi, > >>>> > >>>> The first part of this documentation is now online: > >>>> https://github.com/openjump-gis/openjump-migration-doc > >>>> > >>>> It focuses only on the migration from SVN to Git. > >>>> > >>>> Before migrating, the reading of this article could be useful as it > >>>> contains some good practice tips: > >>>> > https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git > >>>> > >>>> > >>>> Eric > >>>> > >>> > >>> ___ > >>> Jump-pilot-devel mailing list > >>> Jump-pilot-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >>> > >> > >> > >> ___ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > > > > > > ___ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP migration documentation
Hi, On 20/08/2020 19:22, edgar.sol...@web.de wrote: On 20.08.2020 19:08, Michaud Michael wrote: Hi, Big thanks for this work Eric, seems to be very well documented. yup, impressively well documented! Thanks. No problem. I think we should take advantage of this work and proceed to a more definitive migration without waiting too much. true. but we should still put out a final "stable" because it'll probably take some time to adapt all those missing extensions. From a technical point of view, the migration process is still going to work in a couple of months. As written in my previous message, this article highlights what needs to be done before the final migration: https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git It is often advised to avoid adding binary files. I wrote a bit about that in the OpenJUMP context: https://github.com/openjump-gis/openjump-migration-doc/blob/master/MIGRATION.md#2-convert-the-subversion-repository The migration of the OpenJUMP core repository has been relatively easy but: - the WFS functionalities have been lost along the way. What to do?, - some decisions need to be taken about the way(s) to migrate all the plug-ins (individual repositories? a couple of global ones -- core, plus, experimental, etc. --? a global one?). Their SVN structures differ, so it isn't going to be necessarily easy to deal with that, - would it be easier to create the plug-in manager before the migration? Could it help answering the last questions?, - there are all the questions about the different builds, especially for those which are related to the plug-ins, - is there a better way to link SVN authors with Git authors, rather than using the SourceForge user addresses? (historical commits would thus refer to current Git accounts) - etc. After migration, the current size of the OpenJUMP core as a Git repository is around 540MB. The 'docs' folder size alone is 70MB without the revision history, and 108MB if considered. By externalising it into another Git repository (the revision history would be kept as well), this would reduce the global size of the main core repository by already 20%. Some other folders could be considered. In the long term, this would probably make the global project easier to manage. I just did a quick test to create a private repository for the 'docs' folder. See (you need to be logged in to access it): https://github.com/openjump-gis/doc-test I used a tool directly provided by GitHub to automate the migration (https://github.com/new/import). It is quite handy but it is relatively difficult to create a proper mapping between the SVN and the Git users/authors. So what I would suggest is to create some wiki pages in the newly created openjump-migration-doc repository (https://github.com/openjump-gis/openjump-migration-doc) to write and discuss about the different options. A wiki is an easy way of communication, or issues could be created as well. Once discussed/closed, I could add some proper documentation to crystallise what has been decided. This suggestion, even if first perceived as time consuming, could allow us to migrate most the OJ repositories/components, if not all, in an easier way, and to save some a lot of time in the future. This would also allow, if needed, to restructure some parts of the project now (probably not the code itself, such as the tests, etc., but such as previously described based on the 'docs' folder) rather than later, especially if one goal is to reduce the global size of the repository. Once again, these are just suggestions, open to discussion. Eric What about listing the tickets or tasks we want to fix before migration (if possible something we can achieve within a few weeks). Then we could make a new release and concentrate on the migration. agreed. we should at least prioritize. let me try to set up a milestone in the bug tracker. sorry for spamming the list, but setting up the searchable milestone on sf.net was a bit bothersome. we have 36 open bugs, which can now be assigned to a OJ_1.16 milestone now. when that's done we can search them on the left side via 'Open Tickets for OJ 1.16' and fix em one by one. hands up. who want's to tag'em? Any other proposal somebody ? not me :).. ede Michaël envoyé : 20 août 2020 à 17:58 de : Eric à : jump-pilot-devel@lists.sourceforge.net objet : Re: [JPP-Devel] OpenJUMP migration documentation Just added the documentation to update JTS from 1.14 to 1.17. Eric On 20/08/2020 13:42, Eric wrote: Hi, The first part of this documentation is now online: https://github.com/openjump-gis/openjump-migration-doc It focuses only on the migration from SVN to Git. Before migrating, the reading of this article could be useful as it contains some good practice tips: https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git Eric ___ Jump-p
Re: [JPP-Devel] OpenJUMP migration documentation
On 20.08.2020 19:08, Michaud Michael wrote: > Hi, > > Big thanks for this work Eric, seems to be very well documented. yup, impressively well documented! > I think we should take advantage of this work and proceed to a more definitive > migration without waiting too much. true. but we should still put out a final "stable" because it'll probably take some time to adapt all those missing extensions. > What about listing the tickets or tasks we want to fix before migration (if > possible something we can achieve within a few weeks). Then we could make a > new > release and concentrate on the migration. agreed. we should at least prioritize. let me try to set up a milestone in the bug tracker. sorry for spamming the list, but setting up the searchable milestone on sf.net was a bit bothersome. we have 36 open bugs, which can now be assigned to a OJ_1.16 milestone now. when that's done we can search them on the left side via 'Open Tickets for OJ 1.16' and fix em one by one. hands up. who want's to tag'em? > Any other proposal somebody ? not me :).. ede > > Michaël > >> envoyé : 20 août 2020 à 17:58 >> de : Eric >> à : jump-pilot-devel@lists.sourceforge.net >> objet : Re: [JPP-Devel] OpenJUMP migration documentation >> >> >> Just added the documentation to update JTS from 1.14 to 1.17. >> >> Eric >> >> On 20/08/2020 13:42, Eric wrote: >> >>> Hi, >>> >>> The first part of this documentation is now online: >>> https://github.com/openjump-gis/openjump-migration-doc >>> >>> It focuses only on the migration from SVN to Git. >>> >>> Before migrating, the reading of this article could be useful as it >>> contains some good practice tips: >>> https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git >>> >>> >>> Eric >>> >> >> >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > > > > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP migration documentation
Hi,Big thanks for this work Eric, seems to be very well documented.I think we should take advantage of this work and proceed to a more definitive migration without waiting too much.What about listing the tickets or tasks we want to fix before migration (if possible something we can achieve within a few weeks). Then we could make a new release and concentrate on the migration. Any other proposal somebody ?Michaëlenvoyé : 20 août 2020 à 17:58de : Eric à : jump-pilot-devel@lists.sourceforge.netobjet : Re: [JPP-Devel] OpenJUMP migration documentationJust added the documentation to update JTS from 1.14 to 1.17.EricOn 20/08/2020 13:42, Eric wrote:Hi,The first part of this documentation is now online: https://github.com/openjump-gis/openjump-migration-docIt focuses only on the migration from SVN to Git.Before migrating, the reading of this article could be useful as it contains some good practice tips:https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git Eric___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP migration documentation
Just added the documentation to update JTS from 1.14 to 1.17. Eric On 20/08/2020 13:42, Eric wrote: Hi, The first part of this documentation is now online: https://github.com/openjump-gis/openjump-migration-doc It focuses only on the migration from SVN to Git. Before migrating, the reading of this article could be useful as it contains some good practice tips: https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git Eric ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
