Hello All from California -
Please consider using the OSGeo git for specific code repos with
significance. Available at git.osgeo.org to YOU
best regards --Brian M Hamlin MAPLABS
On 8/21/20 5:05 AM, Giuseppe Aruta wrote:
Thanks Eric, next week I will take sometime to study the repository
and all the page you sent.
Some questions, proposals.
A) Regarding plugins,
Do you think that grouping together plugins iwith similar technical
aspects into one source could help to simplify/speed the transition to
Git?
For instance, I am considering to group together CAD toolbox, Advanced
Measure and Color chooser plugins. Of coarse thus should be done
before porting everything to Git.
B) WFS could be shipped as external plug-in. Anyhow.
C) good news from Sextante GIS planet.
https://joinup.ec.europa.eu/svn/sextante/ has also source code from
Sextante vers. 1.0 which seems to be the one we shipped. I recompiled
it with JTS 1.7 and used a OJ core adapted with JTS 1.7 to test
various raster plugins with success.
I am considering to open a repository on Git to store the Sextante lib
source and OJ binding.
Peppe
Il ven 21 ago 2020, 12:37 Eric <eric.openj...@thefactory.io
<mailto:eric.openj...@thefactory.io>> ha scritto:
Hi,
On 20/08/2020 19:22, edgar.sol...@web.de
<mailto: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 <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 <eric.openj...@thefactory.io
<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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
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
