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 <eric.openj...@thefactory.io>
à : 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
