I just renamed master to main so that all the code now appear in the default branch.
You probably will have to clone again your local repo to have a clean install reflecting the remote repository.
We now have to decide if we want to work in a separate dev branch or directly in the main.
Note that working directly in the main does not prevent us to create branches for any change we want to test first or to be reviewed before merging to the main.
envoyé : 20 janvier 2021 à 13:07
de : edgar.sol...@web.de
à : jump-pilot-devel@lists.sourceforge.net
objet : Re: [JPP-Devel] openjump on github
On 1/20/2021 12:54, Eric wrote:
Hi,
On 19/01/2021 13:13, edgar.sol...@web.de wrote:
>> On 1/19/2021 9:19, Michaud Michael wrote:>>> Hi Jumpers
>>>
>>> Thanks to Eric's guide, I could initialize openjump project on gitub (openjump-gis/openjump) and convert it to jts 1.18.
>>>
>>> It is not perfect (I could not convert 1.5 post_release <https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/tags/1.5%20post_release> tag because of the whitespace in the name :-(), but all in all, I think it is OK.
>> tag '1.5 post_release' seems to be there with a %20, or am i missing something?
>>
>>> Please, have a look and let me know if you think so.
>> commit history seem to be identical to sf.net svn, though we're missing 2years because of an improper svn mov from /trunk/openjump to /trunk/core . just for completeness sake we should probably transfer this as into a history branch if someone wants to research changes to a specific source file.
Would you consider creating a specific repository for these 2 years rather than a branch? It would probably reduce the size of the main repository, which is already quite large (~750MB).
See these considerations: https://docs.github.com/en/github/managing-large-files/what-is-my-disk-quota#file-and-repository-size-limitations
sounds perfectly reasonable. these 2 missing years are meant as an archive for researching purposes only anyways.
As the OJ repository will only come larger over time, it could slow the fetching process.
The creation of a specific repository could probably be considered as well to store the former SVN "branches", i.e. oj_stable_1_2 (updated 14 years ago by Stefan Steiniger), 1.2 (updated 14 years ago by Stefan Steiniger), paustin (updated 14 years ago by Paul Austin), 1.3 (updated 12 years ago by Stefan Steiniger), sstein@1863 (updated 11 years ago by Larry Becker) and stable%201.5 (updated 9 years ago by Michael Michaud). All the tags would stay, including the ones in link with the 1.2 and 1.3 versions listed in branches (were these branches some pre-release tests?).
currently we dropped those. looking like private devel/test branches to me which can be discarded.
>>> I could compile but I still have a problem to run maven.
>>>
>>> I did not migrate plugins at all (not sure how we must proceed yet, some options must be discussed)
>> sure, one step after the other. no need to hurry things. generally i'd be in favour of one branch per plugin, but might be swayed otherwise.
Ede, do you mean one repository per plugin rather than one branch?
indeed. no reason to keep all plugins in one plugin repo.
If in the future, the plan is to create/add a plugin manager,
there is, since actually always ;)
>the option to create a repository per plugin could facilitate their maintenance, especially if the OJ distribution can be used as a Maven dependency for these plugins.
totally
>>> There are probably plenty of things to improve and fix before we start again to add new code.
>>>
>>> I'll try to list some more precise points to discuss in a future mail.
>> ok, looking forward to it. ..ede
Eric
thanks!.. ede
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
